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ABSTRACT 


Today’s  planning  and  modeling  systems  use  two-dimensional  (2D) 
representations  of  the  three-dimensional  (3D)  battlespace.  This  presents  a  challenge  for 
planners,  commanders,  and  troops  to  understand  the  true  nature  of  the  battlespace.  This 
thesis  shows  how  3D  visualization  can  give  both  operation  planners  and  executors  a 
better  understanding  of  the  battlespace  that  can  augment  today’s  2D  systems.  Automatic 
creation  of  a  3D  model  for  an  amphibious  operation  allows  the  planner  to  view  an 
operation  order  as  a  whole,  from  different  perspectives.  Recommended  changes  can  be 
made  and  their  effects  immediately  known.  Warfighters  can  use  the  same  tools  for 
mission  preparation  and  review. 

The  United  States  and  NATO  nations  use  the  Land  C2  Information  Exchange 
Data  Model  (LC2IEDM),  formally  known  as  the  Generic  Hub,  as  a  common  method  for 
exchanging  data  between  independent  systems.  As  part  of  the  Scenario  Authoring  and 
Visualization  for  Advanced  Graphical  Environments  (SAVAGE)  project,  this  research 
presents  an  integrated  Web  access  and  3D  visualization  strategy  for  Department  of 
Defense  (DOD)  tactical  messaging  and  operation  orders  using  the  Generic  Hub  data 
model  and  the  Extensible  Markup  Language  (XML).  A  number  of  alternative  yet 
consistent  ways  to  represent  an  amphibious  operation  scenario  demonstrate  the  power, 
flexibility  and  scalability  of  the  SAVAGE  approach. 
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I.  INTRODUCTION 


A.  PROBLEM  STATEMENT 

The  Extensible  3D  (X3D)  and  Virtual  Reality  Modeling  Language  (VRML) 
graphics  provide  a  framework  for  visualizing  an  amphibious  operation  in  a  three- 
dimensional  (3D)  battlespace.  Work  is  in  progress  to  convert  standard  United  States 
Message  Text  Lormat  (USMTL)  documents  into  Extensible  Markup  Language-Message 
Text  Lormat  (XML-MTL)  documents.  Once  done,  VRML  can  translate  the  XML-MTL 
document  one-step  further  and  create  an  auto  generated  3D  scene.  These  3D 
visualizations  can  enhance  amphibious  operation  planning  and  battlespace  awareness. 

B.  OVERVIEW 

Joint  Vision  2020  describes  ways  with  which  to  make  our  Armed  Lorces  faster, 
more  lethal,  and  more  precise.  It  describes  the  significance  of  information  superiority, 
innovation,  interoperability,  and  precision  engagement  among  other  important 
capabilities.  It  recognizes  that  “Information  superiority  will  enhance  the  capability  of  the 
joint  force  commander  to  understand  the  situation,  determine  the  effects  desired,  select  a 
course  of  action  and  the  forces  to  execute  it,  accurately  assess  the  effects  of  that  action, 
and  reengage  as  necessary  while  minimizing  collateral  damage.”  (Joint  Vision  2020,  pg 
22)  It  goes  on  to  say  that  “The  joint  force  must  be  able  to  take  advantage  of  superior 
information  converted  to  superior  knowledge  to  achieve  ‘decision  superiority’-  better 
decisions  arrived  at  and  implemented  faster  than  an  opponent  can  react. ...”  (Joint  Vision 
2020,  pg  8)  This  thesis  aims  to  present  an  innovative,  interoperable  methodology  for 
communicating  and  visualizing  tactical  orders  that  is  in  the  spirit  of  Joint  Vision  2020. 
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Today’s  planning  and  modeling  systems  use  two-dimensional  (2D) 
representations  of  the  three-dimensional  (3D)  battlespace.  This  presents  a  daily  challenge 
for  planners,  commanders  and  troops  to  fully  understand  the  true  nature  of  the  battlespace 
with  regards  to  best  ingress/egress  routes,  areas  that  offer  the  best  cover  and  concealment, 
obstacles  that  may  impede  vehicular  traffic,  and  likely  enemy  strongpoints  or  ambush 
points,  to  name  but  a  few.  By  creating  a  3D  model  of  an  amphibious  operation,  a  2D 
plan  can  be  further  viewed  as  a  whole  from  many  different  perspectives.  Planners  can 
easily  convey  this  information  up  and  down  the  chain  of  command  in  order  to  solicit 
expertise  and  opinion.  Changes  can  be  made  and  their  effects  can  be  viewed  and 
critiqued  instantaneously,  in  context  with  spatial  relationships  preserved.  The  use  of  3D 
is  not  intended  to  replace  2D  maps  and  text-based  descriptions-  rather,  3D  is  an 
additional  tool  needed  in  combination  with  current  techniques.  3D  battlespace 
visualization  may  be  a  key  enabler  to  achieve  “decision  superiority.” 

The  Virtual  Reality  Modeling  Language  (VRML)  and  its  next- generation 
specification,  Extensible  3D  (X3D)  are  Web-based  graphics  languages  for  building  3D 
models.  VRML  allows  user  interaction  within  a  scene  through  viewpoint,  movement, 
and  rotation.  One  of  the  key  features  of  VRML  is  it  is  an  ISO  standard  designed  for  use 
over  the  World  Wide  Web  (WWW).  VRML  has  a  rich  set  of  tools  for  visualizing 
information.  VRML  graphics  palettes  include  colors,  textures,  luminescence,  and 
animations.  These  features  can  be  combined  to  represent  many  different  amphibious 
scenarios.  Amphibious  vehicles,  ships,  and  troops  can  all  be  modeled.  Terrain,  sea  state, 
and  obstacles  can  be  depicted.  All  of  these  models  can  interact  and  move  through  the 
virtual  battlespace  based  on  information  that  the  planners  will  provide. 
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The  US  Message  Text  Format  (USMTF)  has  been  used  jointly  for  all  operational 
message  traffic  since  the  1970’s.  It  includes  accepted  formats  for  countless  message 
types  to  include  operation  orders  and  associated  orders  of  all  types.  However,  with  the 
ongoing  emphasis  on  development  of  the  Extensible  Markup  Language  (XML),  the  free- 
text  syntax  of  USMTL  may  be  reaching  an  end  to  its  usefulness.  The  Extensible  Markup 
Language  (XML)  provides  a  number  of  benefits  over  USMTL  and  has  led  the 
Department  of  Defense  (DoD)  to  establish  an  Extensible  Markup  Language-Message 
Text  Lormat  (XML-MTL)  team  to  focus  on  the  translation  of  USMTL  into  XML. 

This  thesis  seeks  to  translate  and  synthesize  USMTL-based  Operation  Order  data 
messages  written  in  XML  into  a  3D  amphibious -raid  within  a  virtual  battlespace.  By 
combining  the  power  of  XML  and  VRML,  the  end  result  will  be  a  3D  world  populated 
with  aircraft,  ships,  amphibious  vehicles,  and  both  land  and  sea  terrain.  This  virtual 
world  permits  the  viewer  to  navigate  through  an  amphibious  operation  in  both  space  and 
time,  and  thus  to  observe  the  interactions  between  objects  in  that  world. 

C.  MOTIVATION 

Since  World  War  II,  the  Marine  Corps  has  made  itself  known  as  the  premier 

fighting  force  capable  of  accomplishing  successful  amphibious  operations.  Iwo  Jima, 

Tarawa,  and  the  Chosin  Reservoir  landing  are  but  a  few  reminders  of  the  importance  that 

amphibious  operations  have  played  in  our  nations  history.  While  these  operations  were 

eventually  successful,  they  came  at  the  great  cost  of  thousands  of  men’s  lives.  Were  a  3D 

tool,  such  as  this  thesis  introduces,  available  to  commanders  at  the  time  these  operations 

were  executed,  perhaps  a  profound  impact  may  have  been  made  on  many  life-or-death 

decisions.  An  approach  such  as  this  can’t  change  the  past,  but  it  can  have  a  positive 

impact  on  the  future.  Not  only  can  this  technique  help  Marines,  sailors,  soldiers,  and 
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airmen  to  train  for  the  future,  it  can  help  both  the  military  and  the  general  public  learn 
and  possibly  understand  the  crucial  decisions  and  actions  of  the  American  Military,  past 
and  present. 

D.  OBJECTIVES 

This  thesis  demonstrates  and  evaluates  the  functionality  of  a  3D  amphibious 
operation  visualization  using  Extensible  3D  (X3D)  and  the  Virtual  Reality  Modeling 
Language  (VRML).  The  objective  is  to  determine  how  3D  visualization  can  give  both 
operation  planners  and  executors  a  better  understanding  of  the  battlespace  than  is 
currently  available  solely  using  today’s  2D  systems.  To  accomplish  this  objective, 
USMTL  documents  must  first  be  translated  into  XML  documents,  and  then  the  relevant 
data  transformed  into  VRML/X3D  objects.  End-to-end  construction  of  an  exemplar 
amphibious-raid  has  guided  the  design  and  development  presented  here. 

E.  ORGANIZATION  OF  THESIS 

Chapter  II  reviews  background  and  related  information  on  amphibious  operations, 
US  Message  Text  Format  (USMTF),  Extensible  Markup  Language-Message  Text  Format 
(XML-MTF),  Combat  21,  and  operation  and  air  tasking  orders.  Chapter  III  describes  the 
amphibious-raid  scenario  and  introduces  operation  order  design  and  content.  It  also 
introduces  the  scenario  exemplar  operation  orders  and  discusses  potential  limitations. 
Chapter  IV  provides  insight  into  the  NATO  Land  Command  and  Control  Information 
Exchange  Data  Model  (LC2IEDM).  Chapter  V  discusses  the  importance  of  using  a  Web- 
based  approach  and  the  Extensible  Markup  Language  (XML).  The  XML  schemas  for  the 
operation  orders  and  ongoing  efforts  to  further  Web  based  technologies  are  also 
presented.  Chapter  VI  describes  the  scenario  and  visualization  techniques  upon  which 
the  virtual  amphibious -raid  is  based.  Chapter  VII  discusses  scenario -authoring 
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methodologies,  assumptions  and  limitations,  and  presents  the  results  of  the  virtual 
amphibious-raid.  Chapter  VIII  summarizes  the  conclusions  and  recommendations  for 
future  work  of  this  thesis.  The  appendices  present  the  exemplar  operation  orders, 
schemas,  stylesheet,  and  scripted  raid  code. 
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II.  BACKGROUND  AND  RELATED  WORK 


A.  INTRODUCTION 

This  chapter  reviews  concepts  that  are  at  the  root  for  understanding  Marine  Corps 
amphibious  operations.  Subject  matter  includes  amphibious  operations  background, 
Operation  and  Air  Tasking  Orders,  and  the  US  Message  Text  Format  (USMTF). 

B.  AMPHIBIOUS  OPERATION 

1.  Definition 

An  amphibious  operation  is, 

. .  .an  attack  launched  from  the  sea  by  naval  and  landing  forces,  embarked 
in  ships  or  craft  involving  a  landing  on  a  hostile  shore.  (Joint  Publication 
1-02) 

It  is  important  to  note  here  that  the  attack  must  be  launched  from  the  sea,  and  that  the 
landing  be  made  on  a  hostile  shore.  Without  these  two  elements,  there  is  no  amphibious 
operation. 

2.  Types  of  Operations 

There  are  four  types  of  amphibious  operations  that  Marines  may  be  called  upon  to 
perform.  These  include  the  amphibious  assault ,  amphibious -raid,  amphibious 
demonstration,  and  amphibious  withdrawal. 

An  amphibious  assault  is  the  principal  type  of  amphibious  operation.  It  is  usually 
long  in  duration  and  seeks  to  establish  large  landing  forces  on  a  hostile  shore.  An 
amphibious-raid  is  similar  to  an  assault,  except  that  it  is  generally  short  in  duration  and 
has  a  planned  withdrawal.  Raids  may  be  used  for  reconnaissance,  diversions, 
evacuations,  or  as  a  means  to  quickly  inflict  loss  or  damage  on  the  enemy,  to  name  a  few. 
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An  amphibious  demonstration  seeks  to  deceive  the  enemy  with  a  show  of  force,  and 
hopes  to  cause  him  to  adopt  an  unfavorable  course  of  action.  There  is  not  an  actual 
landing  during  a  demonstration.  At  a  predetermined  turn- away  point,  the  forces  will  turn 
around  with  the  hope  that  the  desired  effect  has  been  accomplished.  Finally,  an 
amphibious  withdrawal  is  usually  made  at  the  end  of  an  operation  or  when  it  is 
strategically  or  tactically  determined  to  be  a  necessity.  It  is  not  predetermined,  and  is  one 
of  the  more  difficult  types  of  operation.  (AWS  Ex  Ops  Course,  Vol.  1,  pg.  2-16  -2-17) 

3.  Marine  Air  Ground  Task  Force  (MAGTF) 

There  are  three  basic  and  one  special  MAGTF  types  in  the  Marine  Corps.  Each 
type  consists  of  a  command  element  (CE),  ground  combat  element  (GCE),  air  combat 
element  (ACE),  and  a  combat  service  support  element  (CSSE). 

a.  Marine  Expeditionary  Force  (MEF) 

The  MEF  is  the  principal  warfighting  MAGTF.  It  can  conduct 
amphibious  operations  as  well  as  sustained  operations  ashore.  It  typically  deploys  with 
supplies  that  are  geared  to  last  60  days.  In  addition  to  the  CE,  the  MEF  is  comprised  of  a 
a  reinforced  division  (GCE),  a  Marine  aircraft  wing  (ACE),  and  a  force  service  support 
group  (FSSG)  which  serves  as  the  CSSE. 

b.  Marine  Expeditionary  Unit  (MEU) 

A  MEU  is  usually  deployed  at  sea  in  an  amphibious  ready  group  (ARG), 

and  takes  along  supplies  aimed  at  sustaining  it  for  15  days  of  continuous  operations 

should  it  be  called  to  do  so.  The  MEU  serves  as  a  forward  presence  or  projection  of 

power,  and  can  provide  immediate  response  to  a  crisis  or  contingency  through  its 

capability  of  rapid  deployment.  The  MEU  acts  as  an  advance  force  for  a  larger  MAGTF 

to  follow  if  the  duration  of  the  operation  exceeds  15  days.  In  addition  to  the  CE,  the 
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MEU  is  comprised  of  a  reinforced  infantry  battalion  (GCE),  a  reinforced  medium 
helicopter  squadron  (ACE),  and  a  MEU  service  support  group  (MSSG)  which  serves  as 
the  CSSE. 

c.  Marine  Expeditionary  Unit  Special  Operations  Capable  (MEU(SOC)) 

MEU(SOC)  is  a  certification  that  all  MEUs  attempt  to  obtain  prior  to 

deployment.  A  series  of  special  operations  capable  exercises  (SOCEX)  are  conducted  in 
which  the  MEU  demonstrates  the  ability  to  conduct  varied  special  operations  such  as 
non-combatant  evacuation  operations  (NEOs),  hostage  rescue,  demolition  operations,  and 
civic  action  operations  to  name  a  few.  MEU(SOC)  composition  is  similar  to  that  of  a 
MEU  except  that  it  is  augmented  with  specialized  personnel  and  equipment. 

d.  Special  Purpose  MAGTF  (SPMAGTF) 

SPMAGTFs  are  configured  to  accomplish  a  specific  mission  when  one  of  the 
other  MAGTF  types  is  inappropriate  or  too  large  to  employ.  They  can  be  organized, 
trained  and  equipped  to  conduct  a  variety  of  operations.  In  addition  to  the  CE,  the 
SPMAGTF  is  normally  comprised  of  at  least  a  platoon- sized  element  (GCE),  and  a  task 
organized  ACE  and  CSSE.  (AWS  Ex  Ops  Course,  Vol.  1,  vs.  ID-8  and  9) 

C.  AMPHIBIOUS  PLANNING  DOCUMENTS 

1.  Operation  Order  (OPORD) 

The  Operation  Order  (OPORD)  is  a  directive  issued  by  a  commander  to 
subordinate  commanders  for  the  purpose  of  effecting  the  coordinated  execution  of  an 
operation.  (DoD  Definition).  OPORDs  are  written  at  all  levels  of  command  by  all 
military  services.  One  high-level  OPORD  can  in  turn  generate  numerous  like  OPORDs 
down  to  the  unit- level.  The  format  is  generally  the  same,  with  detail  increasing  as  the 
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order  reaches  the  lowest  unit.  Operation  orders  are  discussed  in  more  detail  in  Chapter 

m. 

2.  Air  Tasking  Order  (ATO) 

The  Air  Tasking  Order  (ATO)  is  used  to  task  and  disseminate  information  to  units 
regarding  projected  sorties,  capabilities,  and  specific  missions.  It  commonly  provides 
instructions  regarding  call  signs,  targets,  aircraft  type/number,  controlling  agencies,  and 
other  general  information. 

Automatically  generating  an  Air  Tasking  Order  and  visualizing  it  in  3D  was  the 
subject  of  Mark  Murray  and  Jason  Quigley’s  thesis,  “Automatically  Generating  A 
Distributed  3D  Battlespace  Using  USMTF  and  XML-MTF  Air  Tasking  Order,  Extensible 
Markup  Language  (XML)  and  Virtual  Reality  Modeling  Language  (VRML)”,  June  2000 
at  the  Naval  Postgraduate  School.  The  proof- of- concept  demonstration  in  that  effort 
provided  the  basis  for  this  work. 

D.  US  MESSAGE  TEXT  FORMAT  (USMTF) 

The  US  Message  Text  Format  (USMTF)  is  the  joint  standard  for  message-based 
information  exchange.  It  facilitates  communications  efficiency  for  joint  and  combined 
forces  by  standardizing  message  formats,  data  elements,  and  information  exchange 
procedures,  (www-  usmtf.itsi.disa.mil) 

USMTF  is  a  government  proprietary  message  standard  for  sharing  structured 
information  (Edwards,  1999,  slide  4).  It  has  the  advantage  of  having  approval  from  all 
DoD  agencies  and  US  allies.  USMTF  represents  a  large  collection  of  Information 
Exchange  Requirements  that  provide  a  standard  vocabulary,  are  platform  independent 
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and  man  readable.  Additionally,  joint  and  international  configuration- management 
processes  support  USMTF.  (Edwards,  1999,  slide  6) 

While  USMTF  is  still  being  used  throughout  the  DoD,  it  has  many  limitations  and 
some  believe  it  is  coming  to  the  end  of  its  useful  life.  With  the  proliferation  of  the 
Extensible  Markup  Language  (XML)  and  the  shortcomings  of  USMTF,  there  is  a  strong 
push  in  the  DoD  to  develop  a  new  standard  called  Extensible  Markup  Language-Message 
Text  Format. 

1.  Extensible  Markup  Language -Message  Text  Format  (XMLrMTF) 

USMTF  has  several  downsides  that  make  it  less  appealing  as  technology 
continues  to  advance.  For  one,  USMTF  is  a  military  proprietary  piece  of  software.  This 
forces  the  government  to  upkeep  and  upgrade  all  aspects  of  USMTF,  precluding  any 
commercial- off- the -shelf  (COTS)  support.  It  also  requires  the  government  to  hire  system 
developers  who  will  have  to  learn  and  adopt  USMTF  standards  in  order  to  engineer 
interfaces.  Because  government -off- the -shelf  (GOTS)  tools  are  expensive  and  lag  far 
behind  the  competitive  COTS  market,  USMTF  is  becoming  a  high-priced  dinosaur. 
(Edwards,  1999,  slide  7) 

Another  shortcoming  to  USMTF  is  its  formatting  rules.  It  was  developed  in  the 
early  1970’s  for  AUTODIN  transport  and  teletype  presentation;  therefore,  USMTF 
format  is  limited  to  display  only  teletype  characters  (capital  letters  and  numbers). 
(Edwards,  1999,  slide  7)  Given  the  vast  number  of  fonts,  formats,  and  the  addition  of 
multi- media  available  in  today’s  presentations,  USMTF  is  somewhat  archaic. 

Finally,  USMTF  can  only  send  messages,  not  metadata.  Metadata  can  be  defined 
as  data  about  data.  That  is,  it  contains  a  description  or  information  on  the  data  being  sent. 
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Metadata  provides  powerful  utility  in  that  individual  consumers  can  search,  filter, 
organize,  or  otherwise  manipulate  data  in  such  a  way  as  to  provide  meaning  that  is  in  line 
with  personal  or  organizational  guidelines. 

In  order  to  try  and  overcome  many  of  these  limitations,  an  initiative  called  the 
Extensible  Markup  Language-Message  Text  Format  (XML-MTF)  was  launched.  In  May 
of  1999,  the  XML-MTF  Development  Team  was  formed  to  attempt  replacing  standard 
USMTF  with  XML  formatted  messages.  The  team’s  charter  was  to  develop  an  XML- 
MTF  specification  and  software  tools  that  transform  messages  between  USMTF  and 
XML-MTF  standards.  This  approach  has  numerous  advantages.  XML  gives  users  the 
ability  to  manipulate  data  in  any  way  they  see  fit,  as  it  includes  metadata. 

Interoperability  issues  can  be  overcome  because  XML  is  easily  exchanged  between 
systems.  These  systems  can,  in  turn,  transform  the  data  using  an  Extensible  Stylesheet 
Language  (XSL)  into  any  format  necessary.  Additionally,  since  XML  is  an  open  Web 
standard,  USMTF  won’t  be  tied  to  a  government  proprietary  standard  any  longer.  This 
will  allow  XML-MTF  to  keep  pace  with  technology  as  well  as  have  a  learned  group  of 
commercial  technicians  available,  who  won’t  have  to  overcome  a  steep  learning  curve 
whenever  XML-MTF  changes  or  updates  need  to  be  made. 

According  to  the  J6I,  “...this  powerful  combination  of  military  and  industry 
standards,  called  XML-MTF,  is  expected  to  drastically  improve  the  warfighter’s  ability  to 
find,  retrieve,  process  and  exchange  tremendous  amounts  of  information  easily  across 
system,  organizational  and  format  boundaries....”  (Edwards,  1999,  slide  10) 
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E.  COMBINED  ARMS  ANALYSIS  TOOL  FOR  THE  21st  CENTURY 

(COMBAT  XXI) 

The  Combined  Arms  Analysis  Tool  for  the  21st  Century  (COMBAT  XXI)  is  a 
non- interactive,  high- resolution  analytical  combat  simulation  system  being  developed  by 
the  US  Army  and  US  Marine  Corps.  The  COMBAT  XXI  model  incorporates  both  land 
and  amphibious  warfare  capabilities,  and  is  designed  to  evaluate  operations  at  the  brigade 
level  and  below.  Among  its  goals  are  interoperability  with  other  models  and  systems, 
plus  alleviation  of  the  difficulties  that  legacy  systems  experience  in  the  scenario- 
development  process.  (Goerger,  2001) 

COMBAT  XXI  adopted  an  open  standard  called  the  High  Level  Architecture- 
Dynamic  Scenario  Builder  (HLA-DSB)  to  handle  the  problem  of  portability.  This 
standard  prescribes  a  basic  format  for  scenario  files,  and  uses  the  Extensible  Markup 
Language  (XML)  as  the  storage  and  interchange  media.  (Goerger,  2001)  By  using 
XML,  COMBAT  XXI  will  reap  the  same  benefits  as  those  of  XML-MTL. 

F.  SUMMARY 

This  chapter  covered  concepts  and  technologies  inherent  to  understanding 
amphibious  operations.  An  amphibious  operation  is  an  attack  that  must  be  launched  from 
the  sea  against  a  hostile  shore.  The  four  types  of  amphibious  operations  are:  amphibious 
assault,  amphibious -raid,  amphibious  demonstration,  and  amphibious  withdrawal.  A 
Marine  Air  Ground  Task  Force  (MAGTF)  is  responsible  for  executing  an  amphibious 
operation  and  varies  in  size  and  structure  depending  on  the  type  and  duration  of  the 
operation.  The  Marine  Expeditionary  Force  (MEF)  is  the  principal  warfighting  MAGTF 
while  the  Marine  Expeditionary  Unit  Special  Operations  Capable  (MEU(SOC))  is  the 
primary  forward  presence. 
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The  Operation  Order,  which  includes  the  Air  Tasking  Order,  is  the  formal  and 
primary  means  of  effecting  the  coordinated  execution  of  an  operation.  These  orders  are 
currently  written  using  the  United  States  Message  Text  Format  (USMTF),  but  are 
currently  being  rewritten  using  the  Extensible  Markup  Language  (XML).  The  resulting 
Extensible  Markup  Language-Message  Text  Lormat  (XML-MTL)  is  expected  to  provide 
more  robust  and  interoperable  data  that  is  more  valuable  to  the  end  users.  The  Combined 
Arms  Analysis  Tool  for  the  21st  Century  (COMBAT  XXI)  is  a  non- interactive,  high- 
resolution  analytical  combat  simulation  system  that  incorporates  land  and  amphibious 
warfare  capabilities.  Like  many  tools  currently  being  developed,  COMBAT  XXI  seeks 
to  leverage  the  robust  benefits  of  XML.  Together,  these  technologies  can  lead  to  an 
integrated  “system  of  systems”  wherein  interoperability  issues  between  services  and 
countries  are  non-existent. 
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ID.  OPERATION  ORDERS  AND  TACTICAL  MESSAGING 


A.  INTRODUCTION 

This  chapter  focuses  on  the  amphibious  invasion  scenario  and  the  operation 
orders  that  accompany  it.  It  describes  the  elements  of  an  operation  order  and  further 
discuss  the  methodology  and  limitations  of  the  operation  order  as  it  is  applied  to  the 
amphibious  scenario.  Finally,  it  examines  Public  Beta  Release  1.02  of  the  MTF2XML 
converter. 

B.  AMPHIBIOUS  INVASION  DESCRIPTION 

This  section  presents  an  imaginary  exemplar  scenario:  Continued  fighting  in 
Koala  between  Snake  National  Forces  and  Apean  Separatists  has  resulted  in  the 
displacement  of  thousands  of  Koalan  non-combatants.  The  non-combatants  have 
attempted  to  flee  towards  the  Apean  and  Monkey  borders  which  has  caused  heightened 
tensions  along  the  Apean/Koalan  border.  To  support  peacekeeping  operations  along  the 
border,  a  forward- operations  base  is  required  in  Ape.  While  the  Apean  Government 
supports  establishment  of  the  airfield,  the  likely  reaction  of  the  civilian  population  is 
unknown. 

Combined  Joint  Task  Force  Blue  has  assembled  off  the  shore  of  “Red  Beach”  in 
preparation  for  an  amphibious -raid  (Figure  3.1).  Marine  Forces  will  disembark 
Amphibious  Ready  Group  (ARG)  shipping  using  Advanced  Amphibious  Assault 
Vehicles  (AAAVs)  under  cover  of  darkness  to  storm  “Red  Beach”  and  proceed  inland  to 
secure  the  airfield  (Figure  3.2).  Marine  AH-  1Z  Super  Cobras  will  provide  cover  and 
support  for  raiding  forces.  A  destroyer  squadron  will  steam  offshore  in  order  to  defend 
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the  ARG  and  provide  fire  support  for  the  raid.  In  addition  to  surface  fleet  support,  one 


submarine  is  in  the  area  of  operation  (AOR)  in  a  direct- support  role. 
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Figure  3.1  Naval  Ships  Assembled  off  the  Shore  of  “Red  Beach” 


Figure  3.2  AAAV  Route  to  Airfield  Represented  As  Waypoints 
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Once  Marine  Forces  have  secured  the  airfield,  they  will  remain  in  position  until 
Army  Apache  helicopters  arrive  and  assume  control  (Figure  3.3).  At  that  time,  all 
Marine  Forces  will  return  to  ARG  shipping  for  completion  of  the  mission. 


Figure  3.3  Marine  Security  Positions  at  Camp  Pendleton  Airfield 


C.  OPERATION  ORDER  DRAFTING  AND  DESIGN 

In  order  to  capture  all  of  the  pieces  of  the  amphibious -raid  above,  it  is  necessary 
to  put  the  information  together  in  a  meaningful  format.  The  operation  order  is  the  format 
of  choice.  As  noted  in  Chapter  II,  an  operation  order  is  a  directive  issued  by  a 
commander  to  subordinate  commanders  for  the  purpose  of  effecting  the  coordinated 
execution  of  an  operation.  While  the  operation  order  is  the  primary  directive,  some 
information  may  be  put  in  other  meaningful  formats  that  are  referenced  in  the  order. 
These  documents  may  consist  of  annexes,  standard  operating  procedures  (SOPs), 
operation  overlays,  or  other  orders. 
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All  operation  orders  have  guidelines  that  are  followed  when  they  are  written. 
“Guidelines”  is  a  key  word  here  because,  while  all  operation  orders  follow  the  same 
format,  the  style  they  are  written  in,  information  that  is  included  or  omitted,  and  the 
amount  of  detail  may  be  vastly  different  from  one  order  to  the  next.  That  said,  all 
operation  orders  have  a  heading,  a  body  and  an  ending  that  consist  of  similar  information. 
The  Amphibious  Warfare  School  provides  an  in-depth  look  at  operation  order  writing  and 
contents  online.  There  is  a  self-paced  text  entitled  Operation  Plans  and  Orders  that  can 
be  accessed  via  the  following  link:  http://www.mcu.usmc.mil/aws/selfpacedText  The 
next  pages  focus  on  each  of  the  sections  and  provide  a  brief  description  of  the 
information  they  contain. 

1.  Heading 

Heading  data  contains  basic  routing  information.  It  is  used  to  handle  the 
administrative  details  of  the  order.  It  generally  includes  the  message  classification;  who 
the  message  is  from;  who  the  message  is  to;  the  date/time  group  (DTG);  a  message 
reference  number;  the  title  of  the  order;  references  referred  to  in  the  order;  and  the  time 
zone  that  will  apply  during  the  execution  of  the  order. 

2.  Body 

The  body  of  the  operation  order  contains  the  meat  of  the  information  needed  to 
execute  the  mission.  There  are  five  paragraphs  within  the  body  of  the  order  that  are 
further  broken  down  into  standard  subparagraphs. 
a.  Situation 

This  paragraph  is  made  up  entirely  of  information  that  is  designed  to 
provide  the  framework  for  the  operation.  It  is  divided  into  six  subparagraphs:  1)  General, 
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2)  Battlespace,  3)  Enemy  Forces,  4)  Friendly  Forces,  5)  Attachments  and  Detachments, 


and  6)  Fegal  Considerations. 

(1)  General.  Used  to  describe  the  political  and  military 
environments  that  may  set  the  conditions  for  execution  of 
the  mission.  It  is  often  omitted  in  OPORDS. 

(2)  Battlespace.  Used  to  describe  the  higher  commander’s 
area  of  operations  and  the  command’s  area  of  interest  and 
operations. 

(3)  Enemy  Forces.  Used  to  describe  enemy  information 
that  may  have  an  effect  on  mission  accomplishment.  This 
information  may  be  alluded  to  in  an  annex  or  other 
document.  If  it  is  included  in  this  paragraph,  information  is 
given  in  the  following  order:  1)  Composition,  Focation, 
Disposition,  and  Movements,  2)  Capabilities,  3)  Enemy 
Courses  of  Action  (most  likely  and  most  dangerous), 

(4)  Friendly  Forces.  Used  to  describe  friendly  forces  that 
may  have  a  bearing  on  the  outcome  of  the  operation.  This 
may  include  the  location,  mission,  and  intent  of  higher, 
adjacent  or  supporting  forces. 

(5)  Attachments  and  Detachments.  Used  to  describe  non- 
organic  units  that  have  been  attached  to,  or  organic  units 
that  have  been  detached  from,  the  headquarters  that  are 
issuing  the  order.  Often  this  will  read  “None.” 
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(6)  Legal  Considerations.  Used  to  describe  only  significant 


conditions  on  which  the  OPORD  is  based.  This  paragraph 
is  routinely  omitted. 

b.  Mission 

This  paragraph  is  used  to  give  a  succinct  account  of  the  WHO,  WHAT, 
WHERE,  WHEN,  and  WHY  of  an  operation  in  order  to  have  enough  information  for 
coordination  and  compliance.  It  does  not  describe  the  HOW. 

c.  Execution 

This  paragraph  is  probably  the  most  important  of  the  entire  operation 
order.  It  describes  HOW  the  mission  will  be  accomplished.  It  contains  six 
subparagraphs:  1)  Commander’s  Intent,  2)  Concept  of  Operations,  3)  Tasks,  4)  Reserves, 
5)  Commander’s  Critical  Information  Requirements  (CCIR),  and  6)  Coordinating 
Instructions. 

(1)  Commander’s  Intent.  Used  to  describe  the 
commander’s  personal  articulation  of  the  purpose  of  the 
operation.  It  is  extremely  important  because,  in  the  event 
of  unforeseen  circumstances,  the  intent  will  guide 
subordinates  to  use  proper  judgment  and  initiative  to 
deviate  from  the  plan,  yet  remain  consistent  with  the 
objectives  of  the  commander. 

(2)  Concept  of  Operations.  This  is  a  summary  statement  of 
HOW  the  commander  wants  the  operation  to  unfold.  In 
some  cases,  the  Concept  of  Operations  may  refer  to  other 

documents,  or  be  an  entire  appendix  of  its  own. 
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(3)  Tasks.  Used  to  assign  tasks  to  subordinate  elements. 
This  paragraph  is  where  each  element  is  told  what  its 
specific  mission  is  with  regards  to  accomplishing  the 
overall  mission.  Assignments  are  given  to  ground 
elements,  aviation  elements,  and  service  support  elements, 
in  that  order. 

(4)  Reserve.  Used  to  assign  the  mission  of  the  reserve 
forces. 

(5)  Commander’s  Critical  Information  Requirements 
(CCIR).  Used  to  describe  both  friendly  and  enemy 
information  that  the  commander  considers  critical  for 
situational  awareness  and  future  planning. 

(6)  Coordinating  Instructions.  Used  to  “send  home” 
information  that  is  applicable  to  everyone  affected  by  the 
order.  Information  may  include,  but  is  not  limited  to,  D- 
day,  H-hour,  L-Hour,  and  coordinates  for  beach  landing 
sites,  helicopter  landing  zones,  and  amphibious  task  force 
objectives. 

d.  Administration  and  Logistics 

This  paragraph  describes  personnel  and  logistical  information  important  to 
the  conduct  of  the  operation.  It  contains  seven  subparagraphs  that  are  described  in  the 
following  order:  1)  Personnel,  2)  Logistics,  3)  Public  Affairs,  4)  Civil  Affairs,  5) 
Meteorological  and  Oceanographic  Services,  6)  Geospatial  Information  and  Services,  and 


7)  Medical  Services.  Each  of  these  subparagraphs  may  be  referenced  to  a  SOP,  or  more 
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commonly,  its  appropriate  annex.  At  the  tactical  level,  subparagraphs  1  and  3-7  are 
routinely  omitted. 

(1)  Personnel.  Used  to  give  instructions  on  timely  and 
accurate  strength  and  accountability  reporting  procedures. 

(2)  Logistics.  Used  to  describe  how  logistics  support  such 
as  transportation,  resupply,  maintenance,  and  general 
engineering  will  be  conducted. 

(3)  Public  Affairs.  Used  to  give  instructions  on  how  to 
deal  with  questions  from  the  local  media. 

(4)  Civil  Affairs.  Used  to  give  instructions  on  how  to 
handle  issues  such  as  requests  for  political  asylum  or 
temporary  refuge. 

(5)  Meteorological  and  Oceanographic  Services.  Used  to 
describe  weather,  tide,  and  other  environmental  factors  that 
may  have  an  impact  on  operations.  Also  discusses  how  this 
information  will  be  updated. 

(6)  Geospatial  Information  and  Services.  Used  to  describe 
the  use  and  update  of  satellite  imagery. 

(7)  Medical  Services.  Used  to  describe  the  locations  of 
hospitals  and  battalion  aid  stations,  their  hours  and  services 
offered,  and  to  give  instructions  on  medevac  procedures. 
Anything  medically  related  may  go  here,  but  will  most 
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likely  be  in  a  separate  annex  or  covered  in  a  separate  CSSE 
order. 

e.  Command  and  Signal 

This  is  the  last  paragraph  in  an  operation  order,  and  is  used  to  provide 
instructions  on  the  proper  establishment  and  maintenance  of  command  and  signal.  It  is 
subdivided  into  four  paragraphs:  1)  Command  Relationships,  2)  Command  Posts  and 
Headquarters,  3)  Succession  to  Command,  and  4)  Signal. 

(1)  Command  Relationships.  Generally  used  in  a  large  or 
complex  operation  in  order  to  easily  ascertain  “who  is 
who”  with  regards  to  command  interaction.  Is  routinely 
omitted  or  referenced  to  its  appropriate  annex. 

(2)  Command  Posts  and  Headquarters.  Used  to  give 
command  post  locations  of  the  orders  issuing  unit  and  those 
of  subordinate  and  higher  units  when  known  or  desired. 

(3)  Succession  to  Command.  Used  to  describe  who  will 
take  over  command  should  the  current  commander  become 
incapacitated  for  any  reason.  This  list  needs  to  be  deep 
enough  to  ensure  there  is  never  a  question  as  to  who  is  in 
command  if  there  needs  to  be  numerous  successions. 

(4)  Signal.  Used  to  describe  the  use  and  meaning  of 
electronic  communications,  pyrotechnics,  and  other 
communication  means. 
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3.  Ending 

Ending  data  is  really  just  a  continuation  of  administrative  information  such  as 
contained  in  the  Heading.  It  generally  contains  the  message  classification,  and  may 
contain  an  authentication,  list  of  annexes  used,  and  a  request  for  acknowledgement. 

D.  OPERATION  ORDER  METHODOLOGY 

There  were  two  overarching  goals  in  writing  the  exemplar  operation  orders  for 
this  thesis.  The  first  is  that  the  operation  be  joint.  The  orders  needed  to  contain  elements 
of  Marine  Corps,  Navy  and  Army  missions  (at  a  minimum)  in  order  to  show  that 
operation  order  visualization  can  work  for  all  services.  The  second  goal  was  that  the 
operation  had  to  be  realistic.  Not  only  did  the  “story”  have  to  seem  real,  but  the  tactics, 
players  and  equipment  needed  to  make  sense  as  well.  To  make  this  happen,  an 
operational  scenario  considered  for  Operation  Noble  Anvil/ Allied  Force  was  used  and 
“rewritten”  to  take  place  off  of  Camp  Pendleton’s  “Red  Beach”  using  surface  and  sub¬ 
surface  ships  from  the  West  Coast  and  Hawaii.  Amphibious  tactics  and  doctrine  were 
drawn  from  experience  and  from  the  Amphibious  Warfare  School  Non-Resident  Program 
textbooks. 

Appendices  B  through  F  contain  the  operation  orders  drafted  for  this  scenario. 
Appendix  B  is  the  top-level  joint  order.  Appendix  C  is  a  lower- level  operations  annex. 
Appendices  D  through  F  are  varying  versions  of  the  unit- level  (specifically  GCE)  orders. 
These  orders  were  written  with  enough  detail  and  structure  to  fulfill  the  intent  of  this 
thesis.  Some  of  the  less-pertinent  guidelines  mentioned  earlier  have  not  been  adhered  to, 
and  much  superfluous  information  has  been  omitted  or  is  incomplete  in  order  to  focus  on 
operation  order  tactical  details  critical  for  visualization.  As  this  thesis  seeks  to  visualize 
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an  amphibious -raid,  its  focus  is  on  the  unit- level  operation  order  (Appendices  D  through 
F).  Therefore  some  of  the  coordinates  for  AORs,  FSAs  and  NFAs  in  the  joint  order  and 
operation  annex  do  not  correspond  to  the  AOR  the  scenario  encompasses.  These 
coordinates  are  provided  as  “filler”  and  have  no  bearing  on  the  outcome  of  this  thesis. 

The  following  paragraphs  briefly  discuss  the  methodology  for  the  unit- level  order, 
and  the  clarifying  simplifications  that  were  taken  to  refine  it  along  the  way.  The 
methodology  is  summarized  in  Appendix  H.  This  summary  also  introduces  the  Generic 
Hub  (GH),  which  is  discussed  in  detail  in  Chapter  IV. 

1.  Unit  Operation  Order  as  a  Word  Document 

While  USMTF  is  the  DoD  standard  for  sending  messages,  it  is  an  extremely 
common  practice  (at  least  in  the  Marine  Corps,  and  conjecturally  in  other  services)  to 
write  orders  as  a  Word  document  and  distribute  copies  (paper  or  e-mail)  to  the 
appropriate  recipients.  This  is  why  the  “first  draft”  of  the  unit  order  is  provided  as  a 
Word  document. 

Figure  3.4  is  the  TASKS  section  of  the  order  (the  complete  order  can  be  found  in 
Appendix  D).  This  portion  communicates  enough  detail  for  tasked  units  to  understand 
the  commander’s  intent  and  be  able  to  write  five  paragraph  orders  of  their  own  that 
further  describe  the  tasks  of  the  individual  components  (platoon,  squad,  fire  team,  etc.). 

It  also  demonstrates  the  desire  to  keep  the  initial  assault  small  and  simple.  It  is  not  an 
oversight  that  an  entire  reinforced  platoon  is  not  likely  to  fit  into  a  single  Advanced 
Amphibious  Assault  Vehicle  (AAAV).  This  was  an  intentional  inaccuracy  in  order  to 
keep  the  amount  of  AAAVs  to  be  visualized  at  a  minimum.  As  the  ability  to  visualize 
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more  complex  scenarios  and  the  number  of  available  models  grows,  future  work  should 
expand  upon  this  scenario  and  add  more  realistic  levels  of  detail. 


B.  TASKS 

1.  1st  PLAT  (REIN),  CO  A 

i.  A  H-HOUR  ( 1500Z ) ,  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED 
BEACH  AND  CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A. 

ii.  YOU  ARE  THE  RECONNAISSANCE  ELEMENT  AND  WILL  LOAD  IN 
AAAV  1 . 

iii  .  ONCE  YOU  REACH  THE  BLS ,  YOU  WILL  FOLLOW  IN  TRACE  OF  2nd 
AND  3rd  PLATOONS  WHILE  DRIVING  TO  ATF  OBJECTIVE  A. 
iv.  UPON  CONSOLIDATION  ON  ATF  OBJECTIVE  A,  ESTABLISH 

PERIMETER  SECURITY  IN  THE  VICINITY  OF  GRID  11SMG673842 
v.  BE  PREPARED  TO  ASSIST  WITH  THE  TURNOVER  TO  TF  APACHE. 

2.  2nd  PLAT  (REIN),  CO  A 

i  .  AT  H-HOUR,  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED  BEACH  AND 
CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A. 
ii.  YOU  ARE  THE  COMMAND  ELEMENT  AND  WILL  LOAD  IN  AAAV  2. 

iii.  ONCE  YOU  REACH  THE  BLS,  YOU  WILL  FOLLOW  IN  TRACE  OF  3rd 
PLATOON  WHILE  DRIVING  TO  ATF  OBJECTIVE  A. 

iv.  UPON  CONSOLIDATION  ON  ATF  OBJECTIVE  A,  ESTABLISH 

PERIMETER  SECURITY  IN  THE  VICINITY  OF  GRID  11SMG664839. 

v.  BE  PREPARED  TO  ASSIST  WITH  THE  TURNOVER  TO  TF  APACHE. 

3.  3rd  PLAT  (REIN),  CO  A 

i.  AT  H-HOUR,  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED  BEACH  AND 
CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A. 
ii.  YOU  ARE  THE  SECURITY  ELEMENT  AND  WILL  LOAD  IN  AAAV  3. 
iii.  UPON  CONSOLIDATION  ON  ATF  OBJECTIVE  A,  ESTABLISH 

PERIMETER  SECURITY  IN  THE  VICINITY  OF  GRID  11SMG676853. 


Figure  3.4  Unit  Operation  Order  TASKS  Section  excerpted  from  Appendix  D 


2.  USMTF  “Enhanced”  Order 

The  next  step  in  automatically  generating  a  3D  visualization  of  the  operation 
order  was  to  reformat  the  Word  document  into  the  United  States  Message  Text  Format. 
This  was  necessary  in  order  to  run  the  XML2MTF  tool  on  the  order  to  get  it  into  an  XML 
format.  This  was  a  relatively  easy  step,  but  it  became  very  apparent  that  there  was  not 
enough  tactical  information  provided.  In  order  for  the  AAA  Vs  to  move  in  a  virtual 
world,  they  would  have  to  have  some  idea  of  where  to  go,  when  to  go,  and  when  to  stop. 
While  the  traditional  operation  order  would  not  get  to  this  level  of  detail  (except  perhaps 


in  an  annex  or  landing  plan),  it  was  concluded  that  it  was  necessary  to  add  information  to 
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the  order.  After  adding  the  new  information  and  running  it  through  the  XML2MTF  tool, 
it  became  evident  that  the  tool  did  not  distinguish  this  information  from  the  rest  of  the 
general  text.  Knowing  this,  liberties  were  taken  with  the  structure  of  the  TASKS  section 
of  the  order  to  make  defining  tags  and  writing  an  XML  schema  easier.  XML  schemas  are 
discussed  in  Chapter  V.  Figure  3.5  emonstrates  some  of  the  clarifying  changes  that  were 
made  (the  complete  order  can  be  found  in  Appendix  E). 

Most  notably,  an  Organization  section  and  a  Timeline  and  Movement  section 
were  added.  In  the  Organization  section,  each  AAAV  was  given  a  call  sign  for  easier 
identification.  The  original  tasks  given  to  each  platoon  were  modified  to  read  “per 
guidance  in  section  6  of  this  order.”  Section  6,  which  is  the  Timeline  and  Movement 
section,  then  became  the  heart  of  the  order  with  regards  to  important  data  required  for  the 
3D  visualization.  It  now  contains  all  the  necessary  data  that  the  AAAVs  need  to  move. 
Start  times  and  locations,  end  times  and  locations,  waypoints,  and  actions  at  the  objective 
are  given  for  each  phase  of  the  assault  (insertion,  infiltration,  maneuvers  at  the  objective, 
and  exfil).  Currently,  for  sake  of  simplicity,  all  AAAV  movement  is  tied  to  the  lead 
vehicle  with  the  exception  of  movement  at  the  objective.  In  other  words,  the  lead  AAAV 
dictates  the  movement  of  the  other  AAAVs  while  moving  from  ship- to- shore,  and  to  and 
from  the  airfield.  In  order  to  give  each  AAAV  autonomous  movement,  additional 
coordinates  must  be  given  for  each  vehicle  in  every  phase  of  the  assault. 

Finally,  all  coordinates  are  given  in  terms  of  Lat/Long  because  they  are  universal 
and  don’t  change.  To  depict  land  coordinates  by  grid  numbers,  the  type  and  version  of 
the  map  being  used  must  be  specified,  and  the  conversion  program  would  have  to  know 
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how  to  do  the  translation.  This  feature  is  very  important  and  may  possibly  be  added  by 
writing  a  script  for  it,  however,  Lat/Long  suffices  for  purposes  of  this  thesis. 

B.  TASKS 

1.  ORGANIZATION 

1 .  AAA VI 

A.  CALL  SIGN  -  BLUE  DEVIL 
4.  3RD  PLAT (REIN),  CO  A 

A.  AT  H-HOUR,  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED  BEACH  AND 
CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A  PER  GUIDANCE  IN  SECTION  6 
OF  THIS  ORDER. 

6.  TIMELINE  AND  MOVEMENT 

A.  DEPART  SHIP  AT  H-HOUR  (INSERTION) 

1.  START  TIME:  041500ZJUL01 

2.  START  LOCATION:  LAT  N33DEG11 . OOMIN  LONG  W117DEG35 . OOMIN 

3.  END  TIME:  041800ZJUL01 

4.  END  LOCATION:  LAT  N33DEG14 . 9MIN  LONG  W117DEG25 . 7MIN 

B.  TRANSIT  TO  OBJECTIVE  AREA  (INFIL) 

1.  START  TIME : 04180 1 Z JULO 1 

2.  START  LOCATION:  LAT  N33DEG14 . 9MIN  LONG  W117DEG25 . 7MIN 

3.  WAYPOINTS: 

A.  LAT  N33DEG15 . 538MIN  LONG  W117DEG24 . 875MIN 

B.  LAT  N33DEG13 . 976MIN  LONG  W117DEG23 . 328MIN 

C.  LAT  N33DEG17 . 274MIN  LONG  W1 1 7DEG22 . 2 4 1MIN 

4.  END  TIME:  042100ZJUL01 

5.  END  LOCATION:  LAT  N33DEG17 . 885MIN  LONG  W117DEG21 . 144MIN 

Figure  3.5  USMTF  “Enhanced”  Operation  Order  Demonstrating  Changes  in  the 
TASKS  Section  excerpted  from  Appendix  E 
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Table  3.1  summarizes  the  changes  that  were  made  to  the  enhanced  order.  The 
‘(new)’  under  the  Sub -paragraph  heading  signifies  and  additional  sub -paragraph  with 
supplementary  information. 


Section 

Sub-paragraph 

Additional  Information 

Tasks 

Organization  (new) 

Call  signs  for  each  AAAV 

Platoon  Assignments 

Modified  original  verbiage 
to  include  reference  to  sub- 
paragraph  6  of  the  order 

Timeline  and  Movement 
(new) 

Insertion-  start/end  times 
and  start/end  locations 

Infil-  start/end  times  and 
start/end  locations  as  well 
as  a  series  of  waypoints 

Actions  at  the  Objective- 
start/end  times  and  location 
of  each  AAAV 

Exfil-  start/end  times  and 
start/end  locations  as  well 
as  a  series  of  waypoints 

Extraction-  start/end  times 
and  start/end  locations 

Table  3.1  Summary  of  Changes  to  the  USMTF  “Enhanced”  Operation  Order 


29 


3.  XMI^MTF  Order 


Once  the  unit- level  order  was  in  the  USMTF  system,  it  was  possible  to  run  the 
XML2MTF  conversion  tool  on  it.  Figure  3.6  demonstrates  that  the  tool  did  a  good  job  of 
“pulling  out”  administrative  information  such  as  the  exercise  name  and  the  originator  of 
the  order.  However,  Figure  3.7  shows  that  the  tool  takes  the  GENTEXT  data  and  lumps 
it  all  together.  It  is  evident  that  the  information  is  part  of  the  EXECUTION  section  of  the 
order,  but  the  data  within  the  section  is  very  ambiguous  and  not  very  useful.  Because  of 
this,  an  XML  schema  that  can  semantically  capture  this  data  had  to  be  developed.  The 
XML  schema  is  discussed  further  in  Chapter  V.  The  complete  XML-MTF  order  can  be 
found  in  Appendix  F. 


<?xml  version=" 1 . 0 " ?> 

-<order> 

-<exercise_identif i cat ion  setid="EXER" > 
<exercise_nickname>XML01</ exercise_nickname> 

</ exercise_identif ication> 

- <me ss age_i dent ificat ion  setid="MSGID" > 

<message_text_f ormat_±denti tier >ORDER</message_text_f ormat_±dent i tier > 
<or±ginator>BLT  ONE  SLANT  FOUR</originator> 

</message_identif ication> 

-<type_of_order  setid="ORDTYP " > 

<type_o f_plan_order>TASKORD</ type_o f_plan_order> 

<order_or iginator_and_or_number / > 

</ type_of_order> 

-<time_zone  setid="TIMEZONE"> 

<time_zone_zulu>Z</ time_zone_zulu> 

</ time_zone> 


Figure  3.6  XML-MTF  Operation  Order  Showing  Capture  of  Administrative 
Information  excerpted  from  Appendix  F 
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-<general_text_in format ion  set±d="GENTEXT " > 

<gentext_text_indicator>EXECUTION</ gentext_text_indicator> 
<free_text  xml :  space="preserve">  ...B .  TASKS  1.  ORGANIZATION  A. 
AAAV  COMPANY  1.  AAA VI  A.  CALL  SIGN  -  BLUE  DEVIL  2.  AAAV  2  A. 
CALL  SIGN  -  NITTANY  LION  3.  AAAV  3  A.  CALL  SIGN  -  HUSKY  2.  1ST 
PLAT (REIN),  CO  A  AT  H-HOUR  (1500Z),  CONDUCT  AN  AAAV  ASSAULT 
ACROSS  RED  BEACH  AND  CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A 
PER  GUIDANCE  IN  SECTION  6  OF  THIS  ORDER.  PER  GUIDANCE  IN 
SECTION  6  OF  THIS  ORDER,  WITHDRAW  TO  ARG  SHIPPING  AFTER  TF 
APACHE  ASSUMES  CONTROL  OF  THE  AIRFIELD.  C.  YOU  ARE  THE 
RECONNAISSANCE  ELEMENT  AND  WILL  LOAD  IN  AAAV  1.  3.  2ND 

PLAT (REIN),  CO  A  A.  AT  H-HOUR,  CONDUCT  AN  AAAV  ASSAULT  ACROSS 
RED  BEACH  AND  CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A  PER 
GUIDANCE  IN  SECTION  6  OF  THIS  ORDER.  B.  PER  GUIDANCE  IN 
SECTION  6  OF  THIS  ORDER, WITHDRAW  TO  ARG  SHIPPING  AFTER  TF 
APACHE  ASSUMES  CONTROL  OF  THE  AIRFIELD.  C.  YOU  ARE  THE  COMMAND 
ELEMENT  AND  WILL  LOAD  IN  AAAV  2.  4.  3RD  PLAT (REIN) ,  CO  A  A.  AT 

H-HOUR,  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED  BEACH  AND  CONTINUE 
INLAND  TO  SEIZE  ATF  OBJECTIVE  A  PER  GUIDANCE  IN  SECTION  6  OF 
THIS  ORDER.  B.  PER  GUIDANCE  IN  SECTION  6  OF  THIS  ORDER, 
WITHDRAW  TO  ARG  SHIPPING  AFTER  TF  APACHE  ASSUMES  CONTROL  OF 
THE  AIRFIELD.  C.  YOU  ARE  THE  SECURITY  ELEMENT  AND  WILL  LOAD  IN 
AAAV  3.  5.  BLT  RESERVE:  CO  B  A.  AT  H-HOUR,  YOU  ARE  ON 
IMMEDIATE  ALERT  AND  WILL  BE  PREPARED  TO  ASSUME  THE  MISSION  OF 
THE  MAIN  EFFORT.  6.  TIMELINE  AND  MOVEMENT  A.  DEPART  SHIP  AT  H- 
HOUR  (INSERTION)  1.  START  TIME:  041500ZJUL01  2.  START 
LOCATION:  LAT  N33DEG11 . OOMIN  LONG  W1 1 7DEG35 . 0 OMIN  3.  END  TIME: 
0  418  0 0 Z JULO 1  4.  END  LOCATION:  LAT  N33DEG1 4 . 9MIN  LONG 
W117DEG25 . 7MIN  B.  TRANSIT  TO  OBJECTIVE  AREA  (INFIL)  1.  START 
TIME : 041801Z JUL01  2.  START  LOCATION:  LAT  N33DEG1 4 . 9MIN  LONG 
W117DEG25 . 7MIN  3.  WAYPOINTS:  A.  LAT  N33DEG15 . 538MIN  LONG 
W117DEG24 . 875MIN  B.  LAT  N33DEG13 . 97 6MIN  LONG  W1 1 7DEG2 3 . 32 8MIN 
C.  LAT  N33DEG17 . 274MIN  LONG  W117DEG22 .241MIN  4.  END  TIME: 

0  4  210 0 Z JULO  1  5.  END  LOCATION:  LAT  N33DEG1 7  . MIN...  </free_text> 
</ general_text_inf ormation> 


Figure  3.7  XML-MTF  Operation  Order  Showing  GENTEXT  Data  in  Unusable 

Format  excerpted  from  Appendix  F 


E.  OPERATION  ORDER  LIMITATIONS 

While  the  benefits  of  being  able  to  compose  an  operation  order  and  visualize  the 
plan  are  enormous,  there  are  many  limitations  to  using  operation  orders  for  this  purpose. 
This  section  addresses  some  of  the  problems  that  need  to  be  overcome  in  order  to  make 
widespread  use  of  a  tool  like  this. 
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1.  Inconsistent  Applications 

When  it  comes  to  writing  orders,  there  are  inconsistent  applications  regarding 
their  use  both  across  and  within  the  military  services.  One  service’s  operation  order  may 
be  another’s  warning  order,  which  may  be  yet  another’s  fragmentary  order.  Each  can 
contain  similar  information,  but  is  written  differently  and  varies  in  the  level  of  detail.  It 
is  up  to  individuals  to  decide  what  type  of  order  to  write.  Additionally,  guidelines  for 
writing  orders  are  often  misinterpreted  or  misunderstood.  One  order  may  omit  key 
information  that  the  next  order  includes.  No  automatic  completeness  checks  are  currently 
available.  There  is  no  “hard  and  fast”  doctrine  regarding  what  must  be  included  in  an 
order.  Guidelines  are  subject  to  the  interpretation  of  the  individual,  which  results  in 
many  like  orders  with  individual  styles  that  make  them  very  different.  While  this  is  not  a 
showstopper,  until  there  are  XML  DTDs  or  schemas  for  every  possible  type  of  order, 
visualization  capabilities  are  going  to  rely  on  everyo  ne  using  a  standard  operation  order 
with  identical  types  of  information. 

2.  Acronyms 

Personnel  in  the  armed  services  know  what  it  is  like  to  live  in  an  ARE  (acronym 
rich  environment) !  There  are  likely  as  many  acronyms  as  there  are  hours  in  a  year,  and 
many  have  multiple  meanings  (including  acronyms  in  an  acronym!).  It  is  very  difficult  to 
define  a  tagset  that  understands  an  acronym  in  a  way  that  can  be  useful  if  they  are  used 
haphazardly.  While  it  is  not  likely  that  the  use  of  acronyms  will  ever  end,  their 
usefulness  in  an  operation  order  is  questionable.  Overuse  of  acronyms  that  are  not 
understood  by  an  XML  DTD/schema,  or  (even  more  distressing)  the  recipient  of  the 
order  can  render  a  visualization  tool  ineffective. 
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3.  Inconsistent  Semantics 


The  armed  services  pride  themselves  on  being  unique  from  one  branch  to  the 
next.  Oftentimes,  the  same  philosophy  holds  true  with  individual  units  or  specialties  in 
the  same  service.  What  this  valuable  uniqueness  also  tends  to  encourage  is  a  lot  of 
different  terms  or  meanings  (semantics)  for  the  same  thing.  For  instance,  the  Marine 
Corps  wears  “cammies”  while  the  Army  wears  “BDUs”.  While  a  Sergeant  in  the  Marine 
Corps  is  just  that,  the  term  is  used  very  loosely  in  the  Army.  An  E-3  isn’t  the  same  thing 
in  any  of  the  services.  So  how  does  one  go  about  defining  XML  tags  when  there  are  so 
many  differences?  One  way  would  be  to  have  different  tags  for  each  service.  In  this 
way,  service  unique  definitions  would  not  be  an  issue.  However,  what  terminology  needs 
to  be  used  on  a  joint  order,  or  during  an  allied  or  coalition  exercise?  One  possible 
solution  to  jargon  incompatibilities  is  the  Land  Command  and  Control  Information 
Exchange  Data  Model  (LC2IEDM).  This  database  model  has  been  accepted  by  the 
United  States  and  NATO,  and  is  discussed  at  length  in  Chapter  IV. 

4.  Applicability 

Another  limitation  with  regards  to  the  written  operation  order  is  that  it  is  not  used 

consistently  at  all  levels  in  the  chain  of  command.  Often  times  written  orders  come  from 

high  commands  and  get  disseminated  through  the  lower  echelons  in  numerous  ways.  It  is 

not  unheard  of  (and  probably  a  common  practice)  for  the  amphibious -raid  scenario 

presented  in  this  thesis  to  not  be  written  as  an  operation  order  at  all  but  rather  covered  in 

a  confirmation  brief.  Squad  leaders  might  scribble  partial  five-paragraph  orders  on  the 

main  course  box  of  the  Meal  Ready  to  Eat  (MRE),  or  fire  team  leaders  may  simply  give  a 

verbal  order.  Formal  written  orders  take  time  that  many  people  aren’t  willing  to  give  or 

don’t  have.  Getting  everyone  to  write  a  formal  order  in  order  to  visualize  the  outcome 
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may  be  a  daunting  and  unattainable  task.  Nevertheless,  for  nontrivial  operations,  clarity 
and  accountability  are  essential. 

5.  Document  References 

Operation  orders  are  often  just  the  skeleton  in  larger  bodies  of  information.  As 
mentioned  before,  countless  other  documents  may  be  referenced  in  an  operation  order. 
Other  orders,  operation  overlays,  and  SOPs  often  contain  core  information  that  is  needed 
in  order  to  visualize  the  plan.  Appendix  G  lists  twenty- six  (26)  different  annexes  that 
may  be  referenced.  A  joint  or  coalition  order  can  have  myriad  possible  references  that 
may  be  in  several  languages.  In  order  to  capture  the  information  from  each  of  these 
documents,  there  would  have  to  be  a  DTD  or  schema  for  each  one,  the  DTD  or  schema 
would  have  to  be  updated  or  changed  every  time  a  given  document  was  altered,  and  the 
XML  translation  tool  would  have  to  be  able  to  parse  and  differentiate  between  all  the 
possible  documents  that  may  have  been  referenced.  For  this  reason,  it  may  be  necessary 
for  operation  orders  to  become  more  verbose  in  order  to  cut  down  on  the  number  of 
referenced  documents.  This  is  a  shift  from  the  common  thinking  of  brevity  versus 
verbosity,  but  it  will  prove  useful  in  the  long  run  if  clarity  is  improved. 

F.  EXTENSIBLE  MARKUP  LANGUAGE-MESSAGE  TEXT  FORMAT 

(XMLMTF) 

The  United  States  Message  Text  Format  (USMTF)  has  long  been  the  tactical 
messaging  tool  of  choice  for  the  Department  of  Defense.  As  the  Extensible  Markup 
Language  (XML)  continues  to  proliferate  and  gain  momentum  in  the  commercial  sector, 
many  of  its  proponents  have  questioned  the  usefulness  of  the  USMTF  system.  An  XML¬ 
MTF  Development  Team  was  given  the  task  of  converting  orders  from  the  USMTF 
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format  to  an  XML-MTF  format.  While  work  is  ongoing,  a  tool  has  been  developed  that 
takes  a  common  USMTF  message  and  converts  it  into  an  XML-MTF  message. 

1.  Public  Beta  Release  1.02  of  MTF2XML  Converter 

In  July  of  2000,  UnixPros  of  Eatontown,  New  Jersey,  released  version  1.01  of  the 
MTF2XML  converter.  This  tool  takes  an  MTF  message  input  and  creates  an  XML 
message  output.  It  follows  the  mapping  standard  set  forth  in  the  XML-MTF  Mapping 
Public  Working  Draft  that  was  created  by  the  XML-MTF  Development  Team  in  March 
of  2000.  It  is  a  Java-based  program  so  it  can  run  on  various  platforms  without  having  to 
recompile.  The  tool  is  only  guaranteed  to  work  on  Windows  NT  (other  platforms  have 
yet  to  be  tested,  however,  the  message  in  Appendix  F  was  generated  using  Windows 
2000),  and  messages  should  be  viewed  with  Microsoft  Internet  Explorer  5.0  or  higher. 
(Public  Beta  Release  1.02  of  MTF2XML  Converter,  Readme.TXT  file,  July  2000) 

G.  SUMMARY 

The  amphibious  invasion  scenario  for  this  thesis  encompasses  a  joint  exercise 
with  coordinated  Army,  Navy,  and  Marine  Corps  participation.  While  operation  orders 
were  written  for  the  entire  scenario,  the  focus  of  this  paper  is  strictly  on  the  amphibious - 
raid  and  the  unit- level  orders  that  correspond  to  it. 

Operation  orders  are  directives  issued  by  a  commander  to  subordinate 
commanders  for  the  purpose  of  effecting  the  coordinated  execution  of  an  operation. 

There  are  guidelines  on  how  to  write  these  orders  that  are  often  interpreted  in  many  ways. 
All  orders  contain  a  heading,  body  and  ending.  The  body  of  the  order  is  the  most 
important  and  is  made  up  of  five  paragraphs:  1)  Situation,  2)  Mission,  3)  Execution,  4), 
Administration  and  Logistics,  and  5)  Command  and  Signal.  Each  of  these  paragraphs  are 
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comprised  of  numerous  subparagraphs  which  contain  or  make  reference  to  information 
critical  to  the  execution  of  the  mission.  The  Execution  paragraph  is  of  great  importance 
as  it  conveys  the  Commander’s  Intent,  Concept  of  Operations,  and  the  Tasks  for  the 
mission. 

In  writing  these  exemplar  orders,  there  were  two  main  goals.  First,  the  orders  had 
to  be  joint.  Second,  the  orders  had  to  be  realistic.  In  order  to  create  an  order  that  would 
lend  itself  to  proper  tag  definitions  and  provide  information  necessary  for  proper 
visualization,  an  “enhanced”  order  was  created  that  included  timelines  and  coordinates 
for  AAAV  movements.  While  it  was  possible  to  alter  this  exemplar  order  for  purposes  of 
research,  many  limitations  on  the  use  of  operation  orders  exist.  They  are  used 
inconsistently  across  and  within  the  military  services,  acronyms  are  used  without 
remorse,  semantics  are  not  consistent,  and  countless  documents  may  be  referenced  from 
which  data  retrieval  must  be  attempted.  Once  an  order  is  written  and  put  in  the  USMTF 
structure,  the  MTF2XMF  Converter  takes  the  MTF  input  and  outputs  an  XMF  message. 
This  is  a  significant  first  step  in  attaining  a  commonly  defined  message  format  that  is 
interoperable  across  systems. 
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IV.  MODELING  AMPHIBIOUS  PLANNING  AND  OPERATIONS 
USING  THE  NATO  LAND  COMMAND  AND  CONTROL 
INLORMATION  EXCHANGE  MODEL  (LC2IEDM) 

A.  INTRODUCTION 

Future  warfare  will  increasingly  rely  on  ad  hoc  coalition  environments  with 
disparate  communication  and  information  technology  systems.  These  systems  will  need 
to  provide  functionality  and  interoperability  in  order  to  facilitate  the  exchange  of  data 
between  Joint  US  and  Coalition  international  forces.  Prior  to  the  start  of  any  operation, 
Coalition  partners  must  review  and  agree  on  communications  standards  to  abide  by. 
NATO  is  currently  trying  to  overcome  this  recurring  problem  by  evaluating  a  common 
data- interchange  specification  called  the  Land  C2  Information  Exchange  Model 
(LC2IEDM).  The  Naval  Undersea  Warfare  Command  (NUWC)  and  the  Institute  for 
Defense  Analysis  (IDA)  are  working  with  the  Naval  Postgraduate  School  (NPS)  to 
extend  this  primarily  land-oriented  model  to  incorporate  Naval  and  maritime 
representations.  This  chapter  briefly  introduces  the  LC2IEDM  data  model  and  evaluates 
its  suitability  for  representing  amphibious  planning  and  operations. 

A  previous  version  of  portions  of  this  chapter  was  presented  in  an  earlier  thesis. 
(Hunsberger,  2001) 

B.  DATA  INTERCHANGE 

As  individuals  and  groups  progress  along  the  “knowledge  pyramid”  from  data  to 
knowledge,  they  work  to  attain  increasingly  higher  levels  of  understanding.  Systems  that 
are  interconnected  need  structured  formats  for  passing  information.  Structured 
methodologies  allow  one  system  to  pass  specific  information  to  another,  with  the 
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expectation  that  the  other  system  can  correctly  represent  it.  A  command-and-control 


example  might  be  a  Marine  Corps  system  passing  a  structured  message  ‘Squadron  of 
F/A-18s  at  the  air  base’  and  having  an  Army  system  represent  the  information  correctly. 

Data  models  are  used  by  systems  to  provide  format  and  message  structure.  By 
outlining  a  format  and  structure,  the  data  model  provides  the  basis  for  any  system  to  be 
able  to  send  on  data  that  any  other  system  can  understand.  This  information  exchange 
model  does  not  specify  the  way  data  must  be  represented  or  stored  on  a  specific  system. 
It  only  specifies  what  and  how  information  must  be  exchanged  between  different 
systems.  This  significantly  reduces  the  number  of  parameters  that  must  be  specified  and 
gives  system  implementers  freedom  to  extend  the  specifications  to  meet  their  needs. 

The  NATO  C3  Technical  Architecture  (NC3TA)  Interoperability  Reference 
Model  describes  four  levels  for  classifying  a  system’s  interoperability.  They  are: 


Degree  1:  Unstructured  Data  Exchange.  Involves  the  exchange  of 
human- interpretable  unstructured  data  such  as  the  free  text  found  in 
operational  estimates,  analysis  and  papers. 

Degree  2:  Structured  Data  Exchange.  Involves  the  exchange  of  human- 
interpretable  structured  data  intended  for  manual  and/or  automated 
handling,  but  requires  manual  compilation,  receipt  and/or  message 
dispatch. 

Degree  3:  Seamless  Sharing  of  Data.  Involves  the  automated  sharing  of 
data  amongst  systems  based  on  a  common  exchange  model. 

Degree  4:  Seamless  Sharing  of  Information  An  extension  of  Degree  3 
to  the  universal  interpretation  of  information  through  data  processing 
based  on  cooperating  applications.  (NC3TA,  2000) 
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The  LC2IEDM  effectively  lays  the  foundation  for  Degree  3  Interoperability. 
(NATO,  2000)  Designers  can  further  create  systems  that  can  seamlessly  share  data  by 
adhering  to  the  model. 

C.  GENERIC  HUB 

The  Land  C2  Information  Exchange  Data  Model  (LC2IEDM)  is  formally  known 
as  the  Generic  Hub  (GH).  The  name  is  derived  from  the  understanding  that  information 
exchange  requirements  (IERs)  will  change  over  time,  therefore  a  flexible  generic  model 
that  can  serve  as  a  basis  or  hub  for  new  systems  is  needed.  NATO’s  information 
requirement  is  to  define  only  information  to  be  exchanged  versus  modeling  all  the 
information  that  might  normally  be  mandatory  for  a  national  system.  Therefore  the  intent 
of  the  GH  is  to  clearly  specify  the  minimum  set  of  data  to  be  exchanged.  However,  since 
the  model  is  both  flexible  and  generic,  nations  may  compatibly  expand  their  own  data 
structures  or  extend  the  model  to  fit  their  needs.  (NATO,  2000) 

The  primary  goal  of  the  Generic  Hub  model  is  to  serve  as  a  common  information- 
exchange  data  model.  NATO’s  automated  information- exchange  plan  requires  a 
common  specification  and  a  common  structure  for  information  to  be  exchanged.  The 
model  provides  the  basis  for  sharable  structured  information.  It  defines  standard 
elements  of  information  (e.g.  vehicle  AAAV,  and  Location  Grid  543789)  and  can  also 
capture  relationships  between  the  information  (e.g.  AAAV  is  located  at  Grid  543789). 

“As  a  minimum,  the  NATO  nations  wish  to  have  the  GH  Data  Model  preserve  the 
meaning  and  relationships  of  the  information  exchanged  and  thereby  attain  the 
interoperability  associated  with  NATO  Level  5  of  System  Interconnection  (automated 
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exchange  of  data,  with  user- imposed  constraints,  between  C2IS  databases).”  (NATO, 

2000) 

Land  Combat  Operations  serve  as  the  common  core  of  the  Generic  Hub. 
Functional  areas  are  referred  to  as  “subfunctional”  areas  of  the  core.  These  subfunctional 
areas  can  be  viewed  as  spokes  extending  from  the  hub  as  shown  in  Figure  4.1.  With  the 
Generic  Hub  serving  as  the  basis  for  the  subfunctional  area  models,  data  common  across 
all  the  areas  is  viewed  and  structured  in  a  standard  way.  (NATO,  2000) 


Combat  Service 
Support  &  Logistics 


Communications 
and  Electronics 


Fire  Support 


Air  Support 


Administration 
(Personnel) 


Engineer 

Operations 


Air  Defense  & 
Airspace  Control 


Intelligence/Electronic  Warfare 
( IEW  ) 


Figure  4.1  Hub  and  Its  Relationship  to  Subfunctional  Areas  (NATO,  2000) 


D.  LAND  C2  INFORMATION  EXCHANGE  DATA  MODEL  (LC2IEDM) 
DATA  SPECIFICATION 

The  Land  C2  Information  Exchange  Data  Model  (LC2IEDM)  (formally  known  as 
the  Generic  Hub)  structure  is  meant  to  be  generic  and  include  all  land,  sea  and  air 
operations.  It  seeks  to  define  the  information  that  is  relevant  to  the  generic  battlespace 
and  also  the  information  that  has  meaning  within  several  of  the  functional  areas.  The 
model  describes  objects  of  interest  including  forces,  equipment,  weather,  terrain  features, 
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and  facilities.  The  data  model  also  includes  information  about  the  relationship  between 
objects.  In  order  to  maintain  a  common  understanding  of  all  content  in  the  model,  use  of 
free  text  (i.e.  unstructured  data)  is  discouraged.  (NATO,  2000) 

The  data  model  has  five  key  and  five  secondary  independent  entities.  The  key 
entities  specify  information  that  directly  addresses  the  battlespace  and  include  OBJECT- 
ITEM,  OBJECT-TYPE,  CAPABILITY,  LOCATION,  and  ACTION.  The  OBJECT- 
ITEM  entity  is  an  individual  object  that  has  some  military  significance.  Examples  are  a 
specific  person  such  as  a  commanding  general  or  a  specific  geographic  feature  such  as  a 
river.  The  OBJECT-TYPE  entity  is  an  individually  identified  class  of  objects  with  some 
military  significance.  This  might  be  a  type  of  facility  (airfield  or  mess  hall),  a  type  of 
person  (rank  or  position),  or  a  type  of  feature  (fire  support  area).  The  CAPABILITY 
entity  denotes  the  ability  to  perform  a  mission  or  function.  The  LOCATION  entity  is  a 
position  within  a  specific  frame  of  reference.  Finally,  the  ACTION  entity  is  an  activity 
or  a  description  of  how  an  activity  will  take  place.  Example  ACTIONS  include  operation 
orders,  fire  missions  and  logistic  requests. 

The  five  secondary  entities  include  CANDIDATE- TARGET- LIST,  CONTEXT, 
REFERENCE,  REPORTING- DATA,  and  RULE- OF- ENGAGEMENT.  These  entities 
provide  information  that  does  not  directly  address  the  battlespace.  For  instance,  the 
REPORTING-DATA  entity  captures  metadata  from  the  other  entities  relevant  to 
command  and  control,  and  the  CONTEXT  entity  is  used  to  group  data  from  other  entities 
without  having  to  create  new  information. 
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The  use  of  these  ten  (10)  entities,  and  the  relationships  between  them,  allows  for 
the  full  specification  of  a  battlespace  situation  that  can  be  transmitted  between  coalition 
systems  to  convey  sharable  information. 

E.  AMPHIBIOUS  MODELING  USING  LC2IEDM 

It  is  worth  emphasizing  that  the  Generic  Hub  (GH)  is  physically  nothing  more 
than  an  extensive  database  governed  by  a  NATO-wide  acceptance  of  common  definitions 
for  the  data  that  is  input.  As  such,  all  modeling  using  the  GH  is  dependent  on  the  entity 
relationships  established  in  the  database.  The  GH  alone  cannot  generate  an  XML 
document,  nor  will  it  unilaterally  fabricate  a  3D  virtual  world.  The  XML  schema 
discussed  in  the  next  chapter  shows  how  information  from  the  GH  can  be  represented 
using  XML,  and  the  stylesheet  example  shows  how  to  covert  one  XML  document  to 
another. 

The  following  figures  demonstrate  different  levels  of  entity- relationship  diagrams. 
Each  entity  can  be  specified  to  the  most  discriminating  level  of  detail  if  desired.  This  is 
important  in  that  the  user  defines  the  preferred  level  of  detail  they  wish  to  model.  Figure 
4.2  is  a  very  simple  diagram  showing  the  relationships  between  the  five  key  entities. 


Figure  4.2  Key  Entities  of  the  Generic  Hub  Data  Model  (NATO,  2000) 
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Figure  4.3  expands  the  level  of  detail  to  include  most  of  the  secondary  entities. 
This  is  still  a  very  high-level  view  of  the  model  but  it  begins  to  illustrate  the  added 
complexity  and  sophistication  available. 


OBJECT-TYPE-CAPABILITY-NORM 


CAPABILITY 


OBJECT-ITEM-CAPABILITY 


Figure  4.3  High-level  View  of  the  Generic  Hub  Model  (Chaum,  2001) 


Figure  4.4  takes  the  ACTION  entity  and  breaks  it  out  into  an  even  finer  level  of 
detail.  Figure  4.4  is  the  foundation  for  demonstrating  how  the  amphibious -raid  scenario 
can  be  modeled,  since  it  illustrates  the  relationships  between  OBJECT- ITEM  and 
OBJECT- TYPE  to  ACTION.  The  demonstration  example  provided  later  focuses  on  the 
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objective  of  securing  the  Camp  Pendleton  Airfield  and  utilizes  the  mapping  structure 
illustrated  in  Figure  4.4. 


ACTION 


Figure  4.4  ACTION,  ACTION-RESOURCE,  and  ACTION- OBJECTIVE  Structure 

(NATO,  2000) 


For  this  example  all  “battlefield  objects”  are  specified  as  instances  of  OBJECT- 

ITEM  (Loaiza,  2001).  In  this  case,  Alpha  Company  and  the  Camp  Pendleton  Airfield  are 
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the  OBJECT-ITEMs.  Additionally,  all  activities  in  the  battlefield  are  represented  as 
instances  of  ACTION  (Loaiza,  2001).  In  the  exemplar  scenario,  Alpha  Company  was 
tasked  with  securing  the  Airfield,  so  the  ACTION  is  given  the  value  “secure”.  The 
NATO  agreed-upon  definition”  in  the  LC2IEDM  specification  for  “secure  is: 


In  an  operational  context,  to  gain  possession  of  a  position  of  terrain  feature,  with 
or  without  force,  and  to  make  such  disposition  as  will  prevent,  as  far  as  possible, 
its  destruction  or  loss  by  enemy  action.  (NATO,  2000) 


The  other  entities  are  described  in  the  following  tables.  Each  table  captures  details  from 
e-mail  correspondence  with  Francisco  Loaiza. 

Table  4.1  expresses  the  way  the  WHO- WHAT  dyad  (who  is  responsible  for  what 
action)  is  represented: 


(a)  ACTION 


action-id 

action-category -code 

action-name 

1101 

OP 

Secure 

(b)  ACTION-RESOURCE 


action-id  action-resource-index 

action-resource-category -code 

1101 

1 

Objectltem 

(c)  ACTION-RESOURCE-ITEM 


action-id  action-resource-index 

object-item -id 

1101 

1 

11 

(d)  OBJECT-ITEM 


object-item -id 

object-item -category -code 

object-item -name 

11 

OR 

Alpha  Company 

Table.4.1  ACTION-RESOURCE  Example  Expressed  using  Generic  Hub  Notation, 
derived  from  (NATO,  2000)  ID  values  are  keys  representing  specific  objects  or  items  in 
the  given  scenario. 
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What  Table  4.1  actually  says  is  that  the  instance  of  OBJECT- ITEM  with  id=ll  (Alpha 
Company)  is  the  resource  for  effectuating  the  instance  of  ACTION  with  id=  1101 
(Secure).  (Loaiza,  2001)  Plainly  stated,  Alpha  Company  will  secure  something. 

Table  4.2  expresses  the  way  the  WHAT-TO_WHOM  dyad  (for  what/whom  is  the 
action  intended)  is  represented.  The  ACTION  table  is  omitted,  as  it  has  not  changed 
from  Table  4.1: 


(a)  ACTION-OBJECTIVE 


action-id  action-objective-index 

action-objective-category -code 

1101 

1 

Objectltem 

(b)  ACTION-OBJECTIVE-ITEM 


action-item  action-objective-index 

object-item -id 

1101 

1 

17 

(c)  OBJECT-ITEM 


object-item -id 

object-item -category -code 

object-item -name 

17 

FE 

Camp  Pendleton  Airfield 

Table  4.2  ACTION-OBJECTIVE  Example  Expressed  using  Generic  Hub  Notation, 

From  (NATO,  2000) 

What  Table  4.1  communicates  is  that  the  instance  of  OBJECT- ITEM  with  id=17  (Camp 
Pendleton  Airfield),  is  the  recipient  of  the  instance  ACTION  id=  1101  (Secure).  In  other 
words,  Camp  Pendleton  Airfield  is  “secured”.  (Loaiza,  2001) 

As  expressed  in  the  entity- relationship  diagram  in  Figure  4.4,  Tables  4.1  and  4.2 
are  not  independent  of  each  other.  When  both  “halves”  are  put  together,  the  model  states 
that  Alpha  Company  is  the  resource  that  carries  out  the  action  “secure”  against  the 
objective  of  Camp  Pendleton  Airfield. 
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It  is  evident  that  more  data  must  be  recorded  and  many  additional  relationships 
developed  to  complete  even  the  simple  amphibious-  raid  model.  One  can  then  surmise 
that  the  magnitude  of  complexity  for  a  large-scale  joint  operation  would  increase 
exponentially.  Nevertheless,  once  information  has  been  recorded  in  the  database,  there  is 
no  need  to  re-enter  the  data  again.  Moreover,  because  the  data  input  is  defined  in  terms 
that  the  US  and  NATO  have  agreed  on,  the  information  can  be  shared  from  one  service  or 
country  to  another. 

F.  LC2IEDM  AND  XMIAMTF 

By  now  it  should  be  apparent  that  the  Generic  Hub  (GH)  and  XML-MTF  models 
are  very  complementary.  XML-MTF  provides  a  set  of  tags  that  capture  all  of  the 
message  header  and  ending  administrative  information,  as  well  as  each  section  within  the 
operation  order.  While  it  further  breaks  the  operation  order  down  into  Situation,  Mission, 
Execution,  etc.,  it  typically  consolidates  all  of  the  content  (GENTEXT)  into  a  large, 
unusable  single  tag.  On  the  other  hand,  the  GH  schema  (when  complete)  can  provide 
semantic  tags  that  fully  capture  and  structure  the  content  of  the  operation  order.  More 
importantly,  US  and  NATO  forces  have  agreed  upon  these  semantic  terms,  making  them 
compatible  for  coalition  use.  When  used  together,  each  process  can  leverage  off  the 
strengths  of  the  other  without  having  to  duplicate  the  effort  of  creating  tags  that  have 
already  been  defined. 

G.  SUMMARY 

The  Land  C2  Information  Exchange  Data  Model  (LC2IEDM)  (formally  known  as 
the  Generic  Hub  (GH))  increases  the  effectiveness  and  efficiency  of  dissimilar  systems 
that  require  data  exchange.  The  data  model  supports  information  interchange  by 


standardizing  the  measures  in  which  the  data  is  exchanged.  The  model  is  generic  in  order 
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to  offer  the  flexibility  necessary  to  permit  the  creation  of  a  full  range  of  battlespace 
representations  over  a  wide  spectrum  of  military  operations. 

The  Generic  Hub  (GH)  is  an  extensive  database  that  depends  on  the  arrangment 
of  potentially  large  sets  of  entity- relationships  to  complete  a  model.  The  example  of 
securing  the  Camp  Pendleton  Airfield  demonstrated  some  of  the  relationships  that  are 
created  between  entities.  It  is  up  to  the  author  to  determine  the  level  of  detail  desired 
when  creating  an  order  or  plan.  The  more  data  desired,  the  more  complex  the  structure  of 
the  model  for  the  order  of  plan  becomes.  However,  once  information  has  been  recorded 
in  the  database,  there  is  no  need  to  reenter  the  data  again.  Also,  because  the  data  entered 
is  defined  in  terms  that  have  been  agreed  upon,  the  information  can  be  shared  from  one 
service  or  country  to  another. 

Finally,  the  LC2IEDM  and  XML-MTF  schemas  are  complementary  to  one 
another.  The  XML-MTF  tags  essentially  capture  the  administrative  information  and 
message  format  while  the  LC2IEDM  tags  capture  the  content  (GENTEXT)  of  the 
message.  By  using  the  two  together,  they  can  leverage  each  other’s  strengths  and 
eliminate  the  need  to  duplicate  the  effort  of  recreating  semantic  tags  that  have  already 
been  defined. 
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V.  WEB  ACCESS  AND  XML 


A.  INTRODUCTION 

The  chapter  discusses  reasons  for  using  the  World  Wide  Web  as  a  medium  to 
distribute  and  utilize  the  visualization  tool.  It  also  introduces  the  Extensible  Markup 
Language  (XML)  and  the  schemas  and  stylesheet  that  are  being  generated  for  the 
amphibious-raid  scenario.  It  concludes  by  describing  several  current  efforts  that  are 
underway  within  the  DoD  and  commercial  sectors  that  are  also  committed  to  the  Web 
and  XML. 

B.  WHY  USE  A  WEB  APPROACH? 

The  phrase  “Web3D  content”  refers  to  3D  graphics  rendered  via  a  web  browser, 
such  as  a  3D  plugin  operating  inside  Microsoft  Internet  Explorer  or  Netscape 
Communicator.  3D  content  needs  to  be  as  easy  to  access  and  view  as  2D  text  and 
graphics  in  a  Hypertext  Markup  Language  (HTML)  document  using  the  browser.  This 
distinction  is  important  if  scalability,  ubiquity,  and  “ease  of  use”  are  to  be  attained. 
(Blais,  2001) 

3D  content  must  be  accessible  via  networked  browsers  in  order  to  grow  and 
interconnect  without  bounds.  This  is  different  from  the  separate-program  installation 
methodology  required  by  most  standalone  or  large-scale  multi-player  online  games.  Lor 
commercial  reasons  (i.e.,  billing  for  services),  most  large-scale  commercial  online  games 
are  separate  customized  applications  that  only  allow  authenticated  users  to  join  and 
depart  shared  virtual  environments.  In  return,  such  distributed  applications  provide  state 
management  and  communications  among  the  host  servers  and  other  players.  The 
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application  further  provides  specialized  (usually  proprietary)  graphics  rendering  that  can 
only  utilize  3D  content  which  is  uniquely  prepared  for  that  application.  While  this  is  an 
effective  business  model  for  online  gaming,  it  is  not  a  very  scalable  or  robust  approach 
for  long-term  military  and  scientific  applications  that  must  steadily  grow  and  improve 
(and  perhaps  even  interoperate).  That  is  why  it  is  important  to  use  open  scalable 
nonproprietary  Web-based  3D  graphics  technologies  that  are  available  today.  (Blais, 
2001) 

C.  EXTENSIBLE  MARKUP  LANGUAGE  (XML) 

This  section  gives  an  overview  of  the  Extensible  Markup  Language  and  further 
discuss  specific  aspects  of  the  language  that  impact  the  research  of  this  thesis. 

1.  Overview 

The  Extensible  Markup  Language  (XML)  was  designed  to  provide  the  simplicity 
of  the  Hypertext  Markup  Language  (HTML)  and  the  information  exchange  benefits  of 
the  Standard  Generalized  Markup  Language  (SGML).  It  became  a  World  Wide  Web 
Consortium  (W3C)  specification  in  Lebruary  1998.  XML  was  created  to  enable  richly 
structured  documents  to  be  employed  on  the  Web;  in  other  words,  it  is  a  markup  language 
for  documents  containing  structured  data.  Two  major  benefits  of  XML  are  that  it  is  free 
and  platform  independent. 

With  HTML,  tag  semantics  and  tag  sets  are  fixed.  XML  does  not  specify 
semantics  or  tags.  Therefore,  XML  semantics  and  tags  are  user  defined.  The  examples 
in  Ligure  5.1  demonstrate  how  HTML  describes  the  format  of  a  document  whereas  XML 
describes  the  structure  and  semantics.  It  is  clear  that  the  XML  tag  has  been  defined  in  a 
manner  that  is  descriptive  and  human  readable.  The  tag  describes  the  data  encapsulated 
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within  it.  The  product  of  data  describing  data  is  referred  to  as  metadata.  This  is  an 


extremely  powerful  and  valuable  function  of  XML.  The  <p>  tag  pair  in  the  HTML 
document  denotes  a  paragraph.  This  construct  is  primarily  for  presentation  purposes  and 
does  not  provide  any  useful  semantic  information.  One  note  of  concern  worth 
mentioning  is  that  because  XML  tags  are  user-defined,  there  are  many  equally  valid  ways 
to  express  the  same  data  using  different  terms  and  structures.  The  uncoordinated  addition 
of  tagsets  will  reduce  data  interoperability  rather  than  improve  it.  (Crawford,  2001) 


A.  HTML  EXAMPLE 

<html> 

<head> 

<title>Department  Heads</title> 

</head> 

<body> 

<p>C0:  Col  Stargazer</p> 

<p>XO:  LtCol  Imnext</p> 

<p>S-l :  CW03  Lostit</p> 

<p>S-2 :  Capt  Knowit</p> 

<p>S-3:  Capt  Writingit</p> 

<p>S-4 :  Maj  Outofit</p> 

<p>S-6:  Maj  Rebootit</p> 

</body> 

</html> 

B.  XML  EXAMPLE 

<R0STER> 

<TITLE>Department  Heads</TITLE> 

<COMMANDING_OFFICER>CO :  Col  St argazer< /COMMAND ING_OFFICER> 
<EXECUTIVE_OFFICER>XO :  LtCol  Imnext</EXECUTIVE_OFFICER> 
<ADMINISTRATION_OFFICER>S-l :  CW03  Lost it </ADMINI STRATION_OFF ICER> 
<INTELLIGENCE_0FFICER>S-2 :  Capt  Knowit < / INTELLIGENCE_OFF ICER> 
<TRAINING_OFFICER>S-3 :  Capt  Writ ingit</TRAINING_OFFICER> 
<SUPPLY_OFFICER>S-4 :  Maj  Outof it</SUPPLY_OFFICER> 

<COMMUNICATIONS_OFFICER>S-6 :  Maj  Rebootit</COMMUNICATIONS_OFFICER> 
</ROSTER> 


Figure  5.1  A.  HTML  Example  for  Presentation  B.  Corresponding  XML  Example  for 

Content  Semantics 
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2.  XML  Components 

While  there  are  many  components  and  rules  for  creating  a  proper  XML  document, 
only  those  that  have  a  direct  effect  on  this  thesis  are  discussed.  There  are  countless 
numbers  of  XMLbooks,  Web  pages,  magazines,  presentations  and  other  resources 
available  for  readers  who  desire  more  information  on  the  subject.  A  good  starting  point 
is  the  World  Wide  Web  Consortium  (W3C)  home  page  at  http://www.w3.org. 

a.  Elements  and  Attributes 

Elements  and  attributes  are  the  fundamental  nodes  used  to  create  XML 
documents.  Elements  consist  of  a  start  and  end  tag,  and  are  characteristically  given 
descriptive  names  to  denote  meaning.  In  Figure  5.1,  <supply_officer>s-4  :  Maj 
Out  of  it  </  supply_officer>  is  the  element  <SUPPLY_OFFICER>  containing  the  data 
“ S-4 :  Maj  Outofit" .  Tag  names  must  begin  with  a  letter,  underscore  or  colon.  Follow  on 
characters  can  be  letters,  numbers,  etc.,  but  cannot  contain  whitespace.  As  noted  earlier, 
it  is  easy  to  depict  the  same  data  using  different  tag  names.  Because  XML  parsers  are 
case  sensitive,  the  element  <SUPPLY_OFFICER>  is  not  the  same  as  <Supply_Officer> 
or  <supply_officer>,  but  (to  humans  at  least)  all  three  versions  clearly  describe  the  same 
data. 

Attributes  enable  an  author  to  define  extra  information  about  an  element. 
Values  given  to  attributes  are  strings  that  must  be  delimited  by  quotation  marks.  An 
example  of  an  attribute  is  <Service  branch=”USMC”>  where  <Ser\’ice>  is  the  element 
with  the  attribute  branch  having  the  value  “ USMC ”.  There  are  arguments  for  and  against 
the  use  of  attributes.  Arguments  against  include  the  inability  of  attributes  to  specify 
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structure,  and  their  tendency  to  inhibit  document  readability  when  they  are  used  in 
excess.  Arguments  for  include  attributes  usefulness  in  describing  the  unique  properties 
of  an  object  and  therefore  increase  the  metadata  provided.  In  any  case,  a  good  rule  of 
thumb  is  to  use  an  attribute  for  simple,  unstructured  “secondary”  information  that  is 
unique  and  cannot  be  separated  from  the  concept  of  the  element. 

b.  XML  Schema 

An  XML  Schema  formally  specifies  a  coherent  set  of  definitions  for 
elements  and  attributes.  Within  the  schema  definition  are  declarations  of  which  elements, 
attributes  etc.  are  legal  within  a  document,  and  also  the  locations  where  they  are  legal. 
(Goldfarb,  2001)  In  other  words,  the  schema  specifies  the  content  and  structure  of  an 
XML  document.  If  a  document  does  not  conform  to  the  XML  specification  it  is  not 
valid. 


The  XML  Schema  is  a  W3C  recommendation  that  was  created  to  improve 
deficiencies  of  the  Document  Type  Definition  (DTD).  DTDs  also  specify  the  content  and 
structure  of  an  XML  document,  but  DTD  document  schemas  are  not  written  in  XML  and 
only  support  character  data.  XML  schemas  make  up  for  these  deficiencies  while 
providing  other  new  capabilities  that  make  it  more  robust  and  powerful  than  a  DTD. 

Some  of  the  extensive  additional  capabilities  that  schemas  provide  include: 

•  New  built-in  data  types  such  as  integers  and  dates; 

•  User-defined  data  types  can  be  created  to  put  additional  constraints  on 
built-in  data  types; 

•  Any  non- negative  whole  number  can  be  used  to  specify  the  number  of 
child  element  occurrences  (formerly  just  zero,  one,  and  infinity  were 
allowed) 

•  Schema  constructs  can  be  imported  from  existing  schemas,  and; 
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•  A  process  called  refinement  enables  elements  to  inherit  content  and 
attributes  from  other  elements.  (Bird,  1999) 

c.  Extensible  Stylesheet  Language  (XSL) 

The  Extensible  Stylesheet  Language  (XSL)  is  a  W3C  specification  for 
applying  standard  formatting  to  XML  documents.  It  is  made  up  of  two  standards:  format 
and  transformation.  The  formatting  standard  defines  the  semantics  of  formatting  in  the 
form  of  a  catalog  of  formatting  objects.  The  transformation  standard  has  evolved  into  a 
language  that  is  autonomously  useful  for  transforming  one  XML  document  to  another.  It 
is  known  as  Extensible  Stylesheet  Language  for  Transformations  (XSLT).  XSL  is  the 
link  between  abstract  data  required  for  computer  processing  and  the  formatted  rendition 
essential  for  human  readability.  XSLT  transforms  a  document  from  an  abstraction  to  a 
rendition.  (Goldfarb,  2001)  By  using  multiple  XSL  stylesheets,  a  single  message  can  be 
formatted  for  text,  HTML,  printing,  or  e-mail. 

D.  XML  SCHEMAS  FOR  THE  AMPHIBIOUS -RAID 

As  discussed  before,  the  XML-MTF  operation  order  is  insufficient  in  the  way  it 
handles  the  GENTEXT  information.  In  order  to  filter  out  the  essential  data  from  the 
TASK  sections,  it  is  necessary  to  create  and  define  another  set  of  XML  tags. 

Lurthermore,  these  tags  need  to  be  compliant  with  the  Generic  Hub  (GH)  in  order  to 
benefit  from  the  coalition  database.  The  XML  schema  in  Appendix  I  defines  the  critical 
information  that  is  needed  for  proper  3D  visualization  of  the  order.  It  leverages  all  of  the 
tags  from  the  XML-MTL  DTD  that  give  the  order  it’s  structure,  but  it  contains  additional 
elements  and  attributes  specifically  designed  to  capture  the  data  from  the  TASKS  section 
of  the  order.  An  ORGANIZATION  element  was  created  to  represent  the  MEU,  BLT, 
Company  and  Platoon.  This  element  is  given  the  attribute  NAME  to  allow  each 
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ORGANIZTION  element  to  be  described  as  15th  MEU  or  Alpha  Company.  Each 
ORGANIZATION  element  may  be  nested  in  another  element  to  form  a  hierarchical 
“parent -child”  structure.  This  enables  Alpha  Company  to  be  an  element  of  the  BLT,  or 
1st  Platoon  to  be  an  element  of  Alpha  Company.  Other  elements  were  added  to  define 
tags  in  the  TIMELINE  AND  MOVEMENT  section  of  the  order.  These  elements  map  to 
the  data  added  to  the  USMTF  “Enhanced”  Order  in  Appendix  E.  In  other  words, 
elements  were  created  for  INSERTION,  INFILTRATION,  WAYPOINT,  etc.  To  account 
for  movement  times,  an  attribute  group  named  START  TIME  was  created  with  attributes 
that  comprise  a  date  time  group  (DTG).  Another  attribute  group  named  LOCATION 
was  created  to  facilitate  defining  locations.  Attributes  in  this  group  include  LAT/LONG 
coordinates,  GH  associated  id  numbers  (used  to  establish  entity  relationships  as  discussed 
in  the  previous  chapter),  and  Names.  While  the  schema  is  still  a  “work  in  progress”,  it  is 
practically  acceptable  in  its  present  state.  Appendix  J  is  an  XML  operation  order  that  has 
been  generated  using  the  new  schema.  This  order  sho  uld  be  compared  with  the  order  in 
Appendix  F  to  get  a  full  appreciation  of  what  the  XML  schema  can  do. 

In  order  for  the  operation  order  in  Appendix  J  to  interoperate  with  the  Generic 
Hub,  another  XML  schema  defines  semantic  tags  that  attempt  to  embrace  all  possible 
elements  incorporated  in  the  database.  This  schema  is  robust  in  that  it  works  for  any 
document  or  order  that  may  utilize  the  element  tags,  not  just  operation  orders.  Segments 
of  this  schema  is  located  in  Appendix  K.  Appendix  L  contains  parts  of  a  GH  compliant 
operation  order  that  follows  the  rules  of  the  GH  schema.  This  order  is  what  the  order  in 
Appendix  J  must  transform  into  to  be  compliant  with  the  database.  An  XSL  stylesheet 
(discussed  in  the  next  section)  is  needed  to  make  that  happen.  Once  the  order  is 
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amenable  to  the  GH  schema,  data  is  entered  into  the  database  by  means  of  a  Visual  Basic 
script. 

E.  XMGMTF  TO  GENERIC  HUB  USING  XSL 

In  order  for  the  operation  order  in  Appendix  J  to  become  the  operation  order  in 
Appendix  L,  and  thereby  compliant  with  the  GH,  an  XSL  stylesheet  is  applied  to  change 
its  format.  Specifically,  XSLT  is  used  to  transform  one  XML  document  into  another. 
Once  this  link  is  complete,  an  extremely  important  chain  reaction  can  occur.  Operation 
orders  can  be  produced  with  the  improved  XML-MTF  schema,  transformed  into  orders 
compliant  with  the  GH  schema  and  read  into  the  database.  However,  this  is  not  a  “one¬ 
way”  feed.  Once  autogeneration  of  the  3D  scene  is  functional,  the  GH  database  will  be 
able  to  feed  and  update  the  information  in  the  scene;  in  other  words  the  data  flow  and 
transformation  works  both  ways.  This  concept  is  made  clearer  in  Appendix  H. 

F.  RELATED  EFFORTS 
1.  Semantic  Web 

The  Semantic  Web  strives  to  make  the  Web  useful  not  only  for  communication 
between  humans,  but  also  to  allow  machines  to  participate  and  help.  Its  goal  is  to  allow 
robots  and  other  automated  tools  to  interpret  information  on  the  Web.  (Semantic  Web 
Activity  Statement,  2001)  “The  Semantic  Web  will  bring  structure  to  the  meaningful 
content  of  Web  pages,  creating  an  environment  where  software  agents  roaming  from 
page  to  page  can  readily  carry  out  sophisticated  tasks  for  users.”  It  is  not  a  separate  Web 
but  rather  an  extension  of  the  current  one.  (Berners-Lee,  May  2001) 

The  Semantic  Web  will  leverage  two  existing  technologies  and  add  a  third 

component  to  round  out  its  development.  The  existing  technologies  are  XML  and  the 

Resource  Description  Framework  (RDF).  The  RDF  is  an  application  of  XML  and  is  used 

56 


to  put  data  into  the  Web  in  a  form  that  can  be  processed  by  machines  using  a  common 
data  model  and  data  schemas  that  can  be  interpreted  by  machines.  (Semantic  Web 
Activity  Statement,  2001)  The  final  component  is  an  ontology,  which  is  a  document  or 
file  that  formally  defines  the  relations  among  terms.  Software  agents  using  this 
component  will  be  able  to  discover  common  meanings  for  terms  across  multiple 
databases.  (Berners- Lee,  2001) 

2.  Task  Force  Web  (TFW) 

Task  Force  Web  is  an  initiative  sponsored  by  the  Department  of  the  Navy  Chief 
Information  Officer  (DON  CIO).  It  seeks  to  Web-enable  the  Navy’s  applications,  and 
uses  XML  as  a  key  element  in  its  architecture.  Building  on  current  Navy- Marine  Corps 
Internet  (NMCI)  and  IT- 21  infrastructures,  TFW  is  to  have  at  least  50  applications  Web- 
ready  by  1  November  2001,  and  all  applications  ready  by  2004.  (TFW,  2001).  X3D, 
XML-based  Generic  Hub  and  XML-MTF  are  all  excellent  candidates  to  become  TFW 
exemplar  systems. 

3.  Geography  Markup  Language  (GML) 

The  Geography  Markup  Language  is  an  XML-based  language  for  encoding 
geographic  information.  It  is  intended  to  enable  the  transport  and  storage  of  geographic 
information  to  include  properties  and  geometry  of  geographic  features.  A  product  of  the 
Open  Geographic  Information  Systems  (OpenGIS)  Consortium,  GML  should  make  an 
impact  on  the  ability  of  organizations  to  share  geographic  information  with  one  another, 
and  to  enable  linked  geographic  datasets.  GML  is  intended  to  describe  the  geography  of 
entities  in  the  real  world,  not  the  visualization  of  geographic  features.  As  such,  GML 
looks  to  transform  its  XML  encoded  features  into  XML  encoded  graphics  elements  such 


as  VRML.  (Johnson,  1999) 
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G.  SUMMARY 

3D  content  must  be  accessible  via  networked  browsers  in  order  to  grow  and 
interconnect  without  bound.  3D  content  needs  to  be  as  easy  to  access  and  view  as  2D 
text  and  graphics  in  a  Hypertext  Markup  Language  (HTML)  document  using  a  browser  in 
order  to  attain  scalability,  ubiquity,  and  “ease  of  use”. 

The  Extensible  Markup  Language  (XML)  was  created  to  enable  richly  structured 
documents  to  be  employed  on  the  Web.  It  was  designed  to  provide  the  simplicity  of  the 
Hypertext  Markup  Language  (HTML)  and  the  information  exchange  benefits  of  the 
Standard  Generalized  Markup  Language  (SGML).  As  a  World  Wide  Web  Consortium 
(W3C)  specification,  XML  is  a  free  and  platform  independent  language.  It  allows  users 
to  define  their  own  tags,  and  therefore  their  own  metadata  (i.e.  data  describing  data)  that 
makes  the  original  structured  information  more  useful  and  readable  to  humans. 

The  XML  schemas  and  stylesheet  for  the  amphibious -raid  are  presented  in  this 
chapter.  One  schema  extends  the  XML-MTF  DTD  by  defining  elements  that  extract  data 
from  the  GENTEXT  portions  of  the  operation  order.  The  other  schema  defines  possible 
elements  incorporated  in  the  GH  database.  The  stylesheet  transforms  one  XML 
document  to  another  XML  document  that  is  compliant  with  the  GH  database.  Generally 
speaking,  an  XML  schema  is  a  catalog  of  definitions  for  elements  and  attributes.  The 
schema  specifies  the  content  and  structure  of  an  XML  document.  The  Extensible 
Stylesheet  Language  (XSL)  is  utilized  for  applying  standard  formatting  to  XML 
documents.  By  using  multiple  XSL  stylesheets,  a  single  message  can  be  formatted  for 
plain  text,  HTML,  printing  or  e-mail. 
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There  are  numerous  efforts  within  the  Department  of  Defense  and  in  the 
commercial  sector  that  are  simultaneously  leveraging  the  benefits  of  XML  and  the  Web. 
The  Semantic  Web,  Task  Force  Web,  and  the  Geography  Markup  Language  are  just  a 
few  examples.  As  XML  progresses  and  XML  tools  become  more  robust,  it  is  clear  that 
XML  will  become  essential  for  most  information  systems. 
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VI.  3D  GRAPHICS  AND  VISUALIZATION 


A.  INTRODUCTION 

This  chapter  describes  concepts  that  are  fundamental  for  understanding  how 
complex  three-dimensional  (3D)  worlds  are  created.  It  discusses  the  Virtual  Reality 
Modeling  Language  (VRML),  DIS-Java-VRML  and  Extensible  3D  (X3D). 

B.  3D  MODELING  AND  VISUALIZATION  TECHNIQUES 
1.  Virtual  Reality  Modeling  Language  (VRML) 

The  Virtual  Reality  Modeling  Language  (VRML)  is  a  Web-based  graphics 

language  for  building  3D  models.  VRML  allows  user  interaction  within  a  scene  through 
viewpoint,  movement,  and  rotation.  One  of  the  key  features  of  VRML  is  it  is  an  ISO 
standard  designed  for  use  over  the  World  Wide  Web. 

VRML  worlds  are  created  using  a  scene-graph  structure.  Scene  graphs  are  simply 
a  hierarchical  decomposition  of  components  that  will  be  rendered  in  a  scene.  Scene 
graphs  are  comprised  of  various  groups  of  nodes,  which  together  form  a  virtual  world. 
These  nodes  are  responsible  for  displaying  shapes,  interaction,  and  movement  through 
the  world.  VRML  worlds  can  be  viewed  with  any  VRML-capable  browser  such  as 
Cosmo  Player  or  Cortona,  which  can  be  downloaded  at  no  cost  from  the  internet  and 
support  both  Internet  Explorer  and  Netscape  as  plug-ins. 

There  are  numerous  examples  of  3D  images  and  objects  available  on  the  Web. 
These  examples  demonstrate  how  groups  of  nodes  are  used  to  create  complex  3D  objects 
and  virtual  worlds.  The  following  list  is  an  excellent  reference  for  3D  examples: 

o  Naval  Postgraduate  School  VRML  Course  examples  are  available  at 
http://www.web3D.org/TaskGroups/x3d/translation/examples/toc.html 
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o  VRML  Sourcebook  examples  at 

http://www.web3D.org/TaskGroups/x3d/translation/examples/Vrml2.0Sou 

rcebook/toc.html 

o  VRML/X3D  Conformance  examples  at 

http://www.web3D.org/TaskGroups/x3d/translation/examples/Conforman 

ce/toc.html 

o  Scenario  Authoring  and  Visualization  for  Advanced  Graphical 

Environments  (Savage)  project  at 

http :  //web  .nps .  navy  .mil/~brutzman/S  avage/toc .  html 

a.  Visual  Nodes 

Visual  nodes  are  the  foundation  for  generating  3D  virtual  worlds.  The 
Shape  node  is  the  node  in  which  the  form  and  appearance  of  a  3D  object  are  defined. 

The  Shape  node  consists  of  four  primitive  shapes:  Box,  Cylinder,  Cone,  Sphere.  Each 
shape  can  be  manipulated  by  changing  field  values  such  as  the  radius  of  a  sphere  or  the 
height  and  width  of  a  box.  In  addition  to  manipulating  the  shapes,  each  shape  has  an 
Appearance  node  in  which  material  and  texture  fields  can  be  changed.  The 
Material  node  allows  the  user  to  choose  colors,  shininess,  transparency,  and  how 
bright  or  dull  the  color  will  be.  The  Texture  node  allows  the  user  to  apply  a  2D  texture 
(such  as  brick  or  water)  to  a  3D  object  to  increase  realism.  In  addition  to  changing  the 
appearance  and  texture  of  a  shape,  other  nodes  are  available  that  allow  the  user  to 
translate,  rotate,  size,  and  orient  the  shape  within  the  scene  graph. 

Shape  nodes  are  not  limited  to  the  primitive  geometries  mentioned  above. 
Advanced  geometries  exist  that  allow  the  user  to  create  more  complex  objects  and  closely 
approximate  smooth  surfaces  and  terrain.  These  nodes  include  (but  are  not  limited  to) 
IndexedFaceSet,  Extrusion,  and  Elevation  Grid.  Figures  6.1  and  6.2 
demonstrate  how  complex  objects  can  be  built  using  a  variety  of  visual  nodes. 
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Figure  6.1  Landing  Craft  Air  Cushioned  (LCAC)  Exiting  the  Well  Deck  of  a  San 

Antonio  Class  LPD-17 


hfl  J- D.  _l  -'SilL-i,:—  7  k.  i  *-  Ok  J. 

Figure  6.2  AH-1Z  Super  Cobra  Patrolling  “Red  Beach”  at  Camp  Pendleton 
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b.  Grouping  Nodes 

Grouping  nodes  are  used  to  band  other  nodes  into  a  common  entity,  and 
then  treat  and  manipulate  that  entity  as  a  whole.  The  Group  node  is  the  most  basic  of 
these  nodes,  and  simply  serves  as  a  container  for  children  nodes.  More  powerful  is  the 
Transform  node,  which  allows  a  builder  to  manipulate  an  entity’s  size,  position,  and 
orientation  within  its  own  coordinate  system.  This  node  allows  large  parts  of  a  virtual 
world  to  be  manipulated  at  one  time. 

c.  Viewing  Nodes 

Viewing  nodes  are  used  to  set  up  predefined  “camera”  viewpoints  within  a 
virtual  world.  A  Viewpoint  node  is  used  to  predefine  a  position  and  orientation  that 
automatically  takes  a  viewer  to  that  location  when  first  entering  the  world.  Additional 
viewpoints  can  be  defined  that  enable  the  viewer  to  easily  navigate  to  predetermined 
areas  throughout  the  world.  These  viewpoints  can  be  selected  randomly  from  a  simple 
Graphical  User  Interface  (GUI)  list,  or  visited  in  order  by  simply  using  the  Page  Down 
key  on  the  keyboard.  Viewpoints  are  very  important  when  trying  to  navigate  through 
large,  complex  virtual  worlds.  Predetermined  viewpoints  do  not,  however,  disable  a 
viewers  ability  to  self  navigate  through  a  virtual  world.  Another  viewing  node  is  the 
Navigat ionlnf o  node.  This  node  determines  how  a  viewer  navigates  through  a 
world.  This  node  can  be  set  to  let  a  user  walk,  fly,  or  examine  the  world  around  them. 

d.  Animation  Nodes 

Once  a  3D  world  is  populated  with  objects,  it  is  usually  desirable  to  make 

it  come  alive.  In  order  to  animate  an  object  in  a  3D  world,  VRML  needs  a  clock, 

interpolator  and  a  route.  A  clock  can  be  created  using  the  Time  Sensor  node  which 

provides  features  for  starting,  stopping  and  controlling  how  quickly  the  animation  plays. 
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The  Posit  ionlnterpolat or  and  Orientat ionlnterpolator  nodes  describe 
the  changes  that  occur  during  an  animation.  Using  a  technique  called  keyframe 
animation,  a  position  or  rotation  is  specified  for  only  a  few,  key  fractional  times.  The 
VRML  interpolator  nodes  use  these  key  fractional  times  and  values  as  a  rough  sketch  of 
the  animation  and  fill  in  the  values  between  those  specified  as  needed.  As  the  animation 
progresses,  new  positions  and  orientations  are  selected  and  output.  (Ames,  1997) 

In  order  to  make  animations  work,  a  circuit  must  be  created  between 
nodes  to  exchange  the  information  that  will  ultimately  make  things  move.  In  order  to  do 
this,  VRML  uses  ROUTE  descriptions.  A  ROUTE  can  take  an  output  from  a 
TimeSensor  node  and  “wire”  it  into  an  input  field  of  an  interpolator  node.  Another 
ROUTE  is  used  to  “wire”  the  interpolator  node’s  output  into  aninput  field  of  a 
Transform  node.  Once  the  circuit  is  complete,  the  TimeSensor  node’s  clock  can  be 
started.  Events  flow  from  the  TimeSensor  node  to  the  interpolator,  and  from  there  to 
the  Transform  node,  causing  the  node’s  coordinate  system  to  translate,  rotate,  and 
scale  as  the  animation  plays  back.  (Ames,  1997) 

e.  Sensor  Nodes 

Sensors  are  the  primary  means  of  providing  interaction  in  a  virtual  world. 
VRML  sensors  are  activated  when  a  cursor,  mouse  arrow,  or  other  pointing  device  is 
moved  over  or  clicked  on  an  object.  When  the  viewer  clicks  on  an  object  with  an 
attached  sensor,  the  sensor  outputs  events  that  can  be  routed  into  other  nodes  to  start 
animations  (Ames,  1997).  The  main  sensor  nodes  are:  TouchSensor, 
PlaneSensor,  SphereSensor,  and  CylinderSensor.  The  nodes  all  act 
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similarly,  but  the  latter  three  provide  the  additional  capability  of  selectively  moving 
objects  within  the  world. 

/.  Script  Node 

The  Script  node  is  used  when  native  VRML  animation  features  are 
insufficient.  This  node  is  used  to  integrate  programs  using  Java  or  JavaScript 
(EcmaScript),  and  can  be  very  powerful  in  creating  more  complex  animations  or 
calculations  in  the  scene  graph. 

g.  PROTO  and  EXTERNPROTO  Definitions 

A  PROTO  (prototype)  and  EXTERNPROTO  (external  prototype)  are  used 
to  create  and  define  a  new  node  type.  A  PROTO  is  usually  a  combination  of  many  other 
nodes  that  have  been  grouped  together  to  make  a  complex  object  that  may  be  useful  or 
necessary  to  reuse.  For  instance,  a  helicopter  may  be  defined  as  a  PROTO  so  as  not  to 
have  to  recreate  it  to  be  used  at  a  later  time.  As  complex  PROTOS  become  common,  it  is 
useful  to  maintain  them  in  your  own  external  library.  An  EXTERNPROTO  declaration  is 
a  reduced  version  of  a  PROTO.  The  EXTERNPROTO  specifies  a  URL  that  points  to  an 
external  file  containing  the  PROTO  (Ames,  1997).  This  provides  for  efficient  network 
storage,  accessibility  and  reuse.  The  corresponding  X3D  nomenclature  for  these 
constructs  is  Prot  oDeclare,  ExternprotoDeclare  and  Protoinstance. 

2.  GeoVRML 

GeoVRML  1.0  is  an  extension  of  the  Virtual  Reality  Modeling  Language 
(VRML)  that  allows  for  accurate  rendering  of  geographic  data.  While  this  thesis  does  not 
make  use  of  GeoVRML  in  its  current  state,  it  is  important  to  discuss  as  it  has  tremendous 
utility  for  follow-on  work. 
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Geo  VRML  1.0  is  a  “Recommended  Practice”  of  the  Web3D  Consortium.  It  is 


open  source  and  freely  downloadable  to  the  public  at  www.geovrml.org.  Geo  VRML  1 .0 
provides  a  suite  of  solutions  for  representing  and  visualizing  geographic  data.  It  provides 
the  following  list  of  high-level  capabilities: 

1.  Coordinate  Systems  -  Geo  VRML  provides  the  ability  to  embed 
latitude/longitude  or  UTM  coordinates  directly  into  a  VRML  file  and  have  the 
browser  transparently  fuse  these  into  a  global  context  for  visualization. 
GeoVRML  1.0  supports  3  coordinate  systems,  21  ellipsoids,  and  1  geoid. 

2.  Precision  -  VRML97  provides  only  single-precision  floating  point  values. 
This  is  insufficient  to  represent  data  on  a  planetary  scale  down  to  around  10  m 
resolution  or  beyond.  GeoVRML  provides  solutions  to  extend  this  precision 
and  enable  sub- millimeter  positional  accuracies. 

3.  Scalability  -  GeoVRML  provides  various  scalability  features  to  manage  the 
streaming  of  large,  multi- resolution  models  over  the  Web. 

4.  Metadata  -  GeoVRML  provides  the  ability  to  specify  a  generic  subset  of 
metadata  describing  geographic  objects,  including  the  ability  to  link  to  a  full 
metadata  description. 

5.  Animation-  The  ability  to  interpolate  within  the  supported  geographic 
coordinate  systems  is  provided  so  that  animations  can  be  defined  with  respect 
to  key  points  on  the  surface  of  the  planet. 

6.  Introspection-  Functionality  is  provided  to  be  able  to  query  a  GeoVRML 
scene  and  discover  the  geographic  coordinate  of  any  georeferenced  point. 

7.  Navigation-  GeoVRML  1.0  provides  some  basic  support  for  navigation 
schemes  that  are  specific  to  geographic  applications.  Specifically,  the  issue  of 
elevation  scaled  velocity  is  addressed. 

GeoVrml  1.0  is  a  suite  of  ten  nodes  designed  to  enhance  virtual  worlds  by  making 
them  geographically  accurate.  Table  6.1  is  an  overview  of  the  nodes.  Following  the 
table  are  more  complete  definitions  for  nodes  that  have  significant  military  application. 
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Node  Name 

Description 

GeoCoordinate 

Build  geometry  using  geographic  coordinates 

GeoElevationGrid 

Define  a  height  field  using  geographic  coordinates 

Geolnline 

Inline  a  file  with  control  over  when  to  load  and  unload  the  data 

GeoLocation 

Georeference  a  vanilla  VRML  model  onto  the  surface  of  the  earth 

GeoLOD 

Level  of  detail  management  for  multi- resolution  terrains 

GeoMetadata 

Include  a  generic  subset  of  metadata  about  the  geographic  data 

GeoOrigin 

Specify  a  local  coordinate  system  for  increased  precision 

Geo  Pos  i  t  i  o  n  I  n  tc  rpo  1  a  to  r 

Animate  objects  within  a  geographic  coordinate  system 

GeoTouchSensor 

Return  the  geographic  coordinate  of  the  object  being  pointer  to 

Geo  Viewpoint 

Specify  viewpoints  using  geographic  coordinates 

Table  6.1.  Nodes  Covered  by  GeoVRML  1.0  Recommended  Practice. 

(Iverson,  2000) 


a.  GeoElevationGrid 

The  GeoElevationGrid  node  lets  users  specify  a  grid  of  elevations 
within  a  geographic  coordinate  system.  These  are  then  transparently  transformed  into  a 
geocentric,  curved-earth  representation.  A  height  field  can  be  created  by  simply 
specifying  all  coordinates  in  terms  of  latitude,  longitude,  and  elevation.  (Iverson,  2000) 
This  allows  for  3D  visualization  of  fingers,  draws,  mountains,  cliffs,  and  other  heightened 
terrain  important  for  the  military  planner.  It  would  help  in  mapping  routes,  possible 
enemy  strongpoints,  and  helicopter  landing  zones  to  name  a  few. 

b.  GeoLocation 

The  GeoLocation  node  provides  the  ability  to  georeference  any 
standard  VRML  model.  That  is,  to  take  an  ordinary  VRML  model  and  specify  its 
absolute  location  on  the  surface  of  the  earth.  (Iverson,  2000)  This  would  allow  military 
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planners  the  ability  to  place  ships,  landing  craft,  tanks,  squads,  artillery  and  other  assets  at 
precise  locations  in  the  virtual  battlespace. 

c.  Geo  Origin 

The  GeoOrigin  node  defines  an  absolute  geographic  location  and  an 
implicit  local  coordinate  frame  against  which  geometry  is  referenced.  This  node  is  used 
to  translate  from  geographical  coordinates  into  a  local  Cartesian  coordinate  system  that 
can  be  managed  by  a  VRML  browser.  (Iverson,  2000) 

d.  GeoPositionlnterpolator 

The  GeoPositionlnterpolator  node  provides  an  interpolator 
capability  where  key  values  are  specified  in  geographic  coordinates  and  the  interpolation 
is  performed  within  the  specified  coordinate  system.  (Iverson,  2000)  The 
GeoPositionlnterpolator  works  much  like  the  Posit ionlnterpolator 
node  in  VRML.  Animation  is  achieved  by  routing  TimeSensor  information  to  the 
GeoPositionlnterpolator,  and  from  the  interpolator  to  the  GeoLocat  ion 
node.  For  example,  an  AAAV  can  be  moved  from  its  initial  location  across  the  water  and 
onto  a  beach  landing  site,  stopping  and  starting  as  necessary  based  on  TimeSensor 
inputs.  Using  this  combination  of  nodes  on  many  ships,  landing  craft,  aircraft,  and 
personnel  would  give  the  planners  the  ability  to  watch  an  entire  amphibious  operation 
unfold  in  3D. 

e.  GeoViewpoint 

The  GeoViewpoint  node  allows  users  to  specify  a  viewpoint  in  terms 
of  a  geographic  coordinate.  This  node  can  be  used  wherever  a  standard  Viewpoint  node 
can  be  used.  A  GeoViewpoint  and  Viewpoint  node  can  be  combined  in  the  same  file. 
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(Iverson,  2000)  The  GeoViewpoint  is  very  valuable  in  that  it  allows  the  user  to  easily 
navigate  through  vast  complex  virtual  worlds.  Because  the  viewpoint  is  in  terms  of  a 
geographic  coordinate,  planners  can  choose  viewpoints  that  will  help  them  see  the  virtual 
battlefield  from  specific  locations  on  key  pieces  of  terrain.  For  example,  if  consideration 
is  being  given  to  move  troops  up  a  draw,  a  viewpoint  could  be  set  at  the  crest  of  a  finger 
looking  down  into  the  draw  in  order  to  get  an  enemy  perspective.  The  outcome  may  be 
to  change  courses  of  action  or  plan  a  new  route.  This  is  invaluable  for  land  and  air  assets 
alike. 


3.  DIS-Java-VRML 

The  Institute  of  Electrical  and  Electronic  Engineers  (IEEE)  Distributed 
Interactive  Simulation  (DIS)  Protocol  is  used  to  communicate  state 
information  (such  as  position,  orientation,  velocities  and  accelerations) 
among  entities  participating  in  a  shared  network  environment.  Java  is  a 
portable  networked  programming  language  that  can  interoperate  on  any 
computer  that  includes  a  Web-browser.  The  Virtual  Reality  Modeling 
Language  (VRML)  enables  platform-  independent  interactive  three- 
dimensional  (3D)  graphics  across  the  Internet,  and  can  be  used  to  compose 
sophisticated  3D  virtual  environments.  (Brutzman,  2001) 

The  DIS-Java-VRML  Working  Group  is  developing  a  free  open-source  software 
library  that  allows  DIS  and  VRML  to  interoperate  by  implementing  Java  code.  Its  goal  is 
to  provide  libraries  and  examples  that  allow  scene  developers  to  build  networked  3D 
worlds  that  are  portable,  pervasive,  scalable  and  viewable  on  any  computer  with  a 
browser  and  network  connection.  (Brutzman,  2001) 

C.  EXTENSIBLE  3D  (X3D) 

The  next-  generation  specification  for  VRML  is  the  Extensible  3D  (X3D)  standard 
(Brutzman,  2001).  X3D  is  a  scene  graph  and  text-based  encoding  designed  to  overcome 
several  limitations  of  the  VRML  standard.  X3D  includes  an  Extensible  Markup  Language 
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(XML)  encoding  to  express  identical  VRML  geometry  and  behavior  structures.  X3D  is 
thus  a  standardized  XML  tagset  for  describing  the  VRML  200x  standard  for  Web- 
compatible  3D  content.  Such  content  is  not  static  but  dynamic,  driven  by  a  rich  set  of 
interpolators,  sensor  nodes,  scripts,  and  behaviors.  (Blais,  2001) 

X3 D/VRML  200x  is  capable  of  compatibly  using  all  legacy  VRML  97  content. 
X3D  provides  new  interoperability  with  other  relevant  standards  including  MPEG- 4  and 
an  entire  family  of  XML-based  languages.  X3D  further  addresses  several  shortcomings 
of  VRML  97,  provides  tighter  media  integration,  improved  visual  quality  through 
advanced- rendering  nodes,  and  enables  a  component-based  approach.  (Blais,  2001) 

Using  the  X3D-Edit  authoring  tool,  developers  can  create  valid  scene  graphs  with 
little  trouble.  The  tool  is  simple  enough  that  even  novice  3D  developers  can  create 
virtual  worlds  with  relative  ease.  When  generating  a  scene,  the  X3D-Edit  software  limits 
the  developer  to  only  see  allowable  choices.  Only  valid  nodes  can  be  selected, 
eliminating  guesswork  and  potential  errors.  X3D-Edit  utilizes  IBM’s  Xeena  XML  editor 
configured  to  work  with  the  X3D  document  type  definition  (DTD).  Documents  are 
translated  into  VRML  using  the  Extensible  Stylesheet  Language  (XSL),  and  a  browser  is 
automatically  launched  for  convenient  debugging.  (Brutzman,  2001)  Figure  6.3  shows  a 
screen  shot  of  the  X3D  Edit  tool. 
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Figure  6.3  Screen  Capture  of  the  X3D  Edit  Tool 


D.  SUMMARY 

The  Virtual  Reality  Modeling  Language  (VRML)  is  a  Web-based  graphics 
language  for  building  3D  models.  VRML  allows  user  interaction  within  a  scene  through 
viewpoint,  movement,  and  rotation.  VRML  worlds  are  created  using  scene  graphs  that 
are  comprised  of  various  groups  of  nodes.  These  nodes  are  responsible  for  displaying 
shapes,  interaction,  and  movement  through  the  virtual  world.  Geo  VRML  1 .0  is  an 
extension  of  VRML  that  allows  for  accurate  rendering  of  geographic  data.  While  not 
used  in  this  thesis,  it  will  be  extremely  useful  to  military  planners  and  should  be  followed 
closely  as  it  becomes  more  robust.  Extensible  3D  (X3D)  is  the  next -generation 
specification  for  VRML.  It  was  designed  to  overcome  some  of  the  limitations  of  the 
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original  VRML  specification  and  incorporates  the  use  of  the  Extensible  Markup 
Language  (XML).  These  technologies  provide  a  scalable  Web-based  approach  to 
networked  3D  graphics  that  is  suitable  for  generation  and  distribution  of  large-scale 
virtual  environments. 


73 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


74 


YD.  EXPERIMENTAL  RESULTS 


A.  INTRODUCTION 

This  chapter  describes  how  the  concept  of  how  to  represent  and  visualize  the 
amphibious-raid  scenario  is  implemented  and  demonstrated.  It  concludes  with  a  number 
of  different  yet  equivalent  methods  for  describing  and  presenting  such  tactical  scenarios. 

B.  SCENARIO  AUTHORING 

1.  Motivation 

The  Director  of  Training  and  Education  Command  at  the  Marine  Corps  Combat 
Development  Command  (MCCDC)  in  Quantico,  Virginia  wanted  to  develop  a  tool  that 
could  “bring  the  basic  concepts  of  amphibious  operations  to  the  masses”.  Believing  in 
the  power  a  tool  like  this  could  deliver  to  the  Marine  Corps,  and  having  recently  been 
exposed  to  VRML  and,  to  a  lesser  degree,  XML,  it  was  clear  that  the  foundation  for 
creating  this  tool  was  already  available.  Armed  with  the  knowledge  that  this  could  be 
done,  it  was  decided  that  an  amphibious-raid  scenario  of  limited  complexity  was  an 
excellent  starting  point  to  begin  modeling  some  of  the  “basics  of  amphibious  operations.” 

2.  Methodology 

In  order  to  author  and  visualize  an  amphibious -raid,  it  was  decided  that  a 
filmmaker  approach  would  be  taken.  Drawing  on  prior  experience  and  using  the 
Amphibious  Warfare  School  Non-resident  Program  Expeditionary  Operations  Course  as 
a  resource,  a  realistic  and  tactically  correct  scenario  was  outlined.  Lrom  the  outline, 
storyboards  were  drawn  to  correspond  to  the  “scenes”  that  were  needed  to  convey  an 
accurate  and  believable  visualization  of  the  scenario. 
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Having  storyboarded  the  entire  scenario,  a  trip  was  made  to  “Red  Beach”  at  Camp 
Pendleton,  California  to  observe  an  amphibious  capabilities  exercise  (CAPEX).  This  was 
an  invaluable  visit  because  it  provided  the  opportunity  to  take  photographs  of  the  terrain, 
aircraft,  landing  craft,  and  ships  that  needed  to  develop  into  3D  models  for  the  scenario. 
Furthermore,  the  luxury  of  observing  a  live- action  operation  enabled  the  storyboard 
vision  to  be  refined  and  take  on  a  new  life  of  its  own. 

While  3D  models  were  being  generated,  each  storyboard  was  coupled  with  an 
actual  photo  that  was  consistent  with  the  “theme”  it  conveyed.  The  next  step  was 
providing  a  text  description  for  each  storyboard/photo  pair  that  put  into  words  what  was 
actually  happening  in  each  scene.  This  permitted  scenes  to  have  deeper  meaning  given 
that  each  set  of  pictures  was  complemented  with  background  and  tactical  information. 

As  models  became  available,  the  visualization  of  the  amphibious-raid  started  to 
take  shape.  Lacking  an  adequate  XML  DTD  or  schema  that  allowed  for  the  conversion 
of  operation  orders  into  automatically  generated  3D  worlds,  a  scripted  version  of  the  raid 
was  created  (see  Appendix  N).  For  each  text  description/storyboard/photo  set,  an 
analogous  screen  capture  was  added  from  the  virtual  raid.  This  added  a  new  level  of 
depth  in  visualizing  how  everything  fit  together. 

Lastly,  the  operation  orders  were  written  as  discussed  previously  in  Chapter  III. 
The  amphibious-raid  and  corresponding  unit- level  orders  were  focused  on  because 
modeling  and  translating  orders  for  the  entire  joint  scenario  would  have  been  attempting 
too  much  too  soon.  Once  written,  the  order  added  yet  another  level  of  depth  in  seeing 
how  everything  tied  together. 
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3.  Tactical  Assumptions  for  the  Amphibious  Raid  Scenario 

In  order  to  keep  the  scenario  realistic,  yet  simple  enough  to  model,  some 
assumptions  had  to  be  made.  These  tactical  assumptions  are  not  meant  to  be  realistic  in 
all  cases,  but  are  sensible  limitations  for  a  generic  example  without  loss  of  generality. 

The  amphibious-raid  takes  place  during  twilight  hours  on  a  calm  sea  (sea- state  is 
0-1  (flat))  where  the  wind  is  less  than  10  knots.  Helicopters  have  been  conducting 
routine  patrols  for  a  number  of  days  prior  to  the  raid.  Since  the  enemy  is  used  to  hearing 
the  helicopters,  there  is  no  suspicion  when  they  are  heard  while  actually  providing  cover 
noise  for  the  raid.  The  raid  is  on  a  hostile  beach,  but  is  generally  clear  of  enemy  troops  or 
fortifications.  This  allows  for  the  entire  raid  force  to  land  in  one  wave. 

The  next  few  ideas  are  notional,  but  important  in  understanding  some  of  the 
decisions  made  for  the  scenario.  Developmental  systems  such  as  the  San  Antonio  class 
LPD-17  and  the  AAAV  are  assumed  to  have  been  fielded  and  fully  employed.  An  ATO 
has  already  been  written  for  the  Super  Cobras-  a  new  ATO  was  not  written  for  this 
scenario  because  the  Quigley/Murray  thesis  handled  this  subject  sufficiently  and  there 
was  no  need  to  repeat  their  work.  Finally,  each  AAAV  holds  a  reinforced  Marine 
platoon. 

4.  Tactical  Limitations 

In  order  to  keep  the  virtual  raid  as  simple  as  possible,  a  number  of  limitations 
were  placed  on  the  scenario:  1)  The  amount  of  vehicles  were  kept  to  a  minimum  and 
don’t  fundamentally  reflect  a  realistic  battlefield  picture  (more  AAAVs  would  have  to  be 
added  to  truly  carry  a  reinforced  company  of  Marines  from  ship- to- shore),  2)  There  is  no 
enemy  contact  or  enemy  obstacles  while  in  transit  to,  or  while  crossing  the  beach  landing 
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site  (BLS),  3)  There  are  no  avatars  representing  individual  Marines,  rather  they  are 
considered  to  be  represented  by  the  AAAV. 


In  order  to  keep  coding  simple  while  manually  scripting  the  scene,  the  AAAVs 
were  made  to  move  as  one  entity  instead  of  individually  (movement  at  the  airfield  is  the 
only  exception).  Because  they  are  bound  together,  individual  movements  1100m  and 
500m  from  the  BLS  are  precluded.  Instead,  the  AAAVs  go  directly  from  ship  to  shore. 
C.  EXEMPLAR  TACTICAL  SCENARIO 

This  section  gives  visual  insight  into  the  methodology  described  earlier.  It 
demonstrates  how  the  text  description,  storyboard,  photo,  and  3D  screen  shot  all  work  in 
parallel  to  describe  the  exact  same  scene.  Operation  orders  are  not  included  here,  as  they 


have  been  discussed  at  length  throughout  this  thesis. 


1.  Scene  10:  Beach  Landing  Site  (BLS) 


Location 

•  Red  Beach,  Camp  Pendleton  California 
Description 

•  Beach  landing  site  on  a  hostile  shore 

•  Morning  hours  of  twilight 
Purpose 


•  Establish  initial  viewpoint  from  objective 


Storyboard 


Photo 


3D  Screen  Shot 
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2.  Scene  20:  Helicopter  Sortie 

Location 


•  Flight  deck  of  the  LPD- 17 
Description 

•  AH-  1Z  Super  Cobra  helicopters  prepare  for  takeoff 
Purpose 

•  Provide  cover  noise  for  the  incoming  raid  force 


Storyboard 


Photo 


3D  Screen  Shot 


3.  Scene  30:  AAA  Vs  Exit  LPD  Well  Deck 


Location 

•  Insertion  point  from  well  deck  of  San  Antonio  class  LPD  - 17 
Description 

•  Three  AAAVs  get  underway 


Purpose 


•  Each  AAAV  has  one  squad  of  Marines 

•  Squads:  command,  recon/security  and  covering  elements 

•  These  squads  comprise  the  raid  force 


Storyboard 


Photo 


3D  Screen  Shot 
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4.  Scene  40:  Helicopters  on  Patrol 

Location 

•  Flying  over  the  Pacific  Ocean  and  Red  Beach 
Description 

•  AH-1Z  Super  Cobra  helicopters  fly  a  regularly  scheduled  reconnaissance 
route 

Purpose 

•  Provide  cover  noise  for  the  incoming  raid  force 


Storyboard  Photo 


3D  Screen  Shot 


5.  Scene  50:  AAAVs  1100m  from  Beach  Landing  Site 

Location 

•  Control  point  1 100m  from  beach  landing  site 
Description 

•  Raid  force  moves  from  a  wedge  to  an  on  hne  formation 
Purpose 

•  Ensure  everything  is  still  a  “go”  before  raid  force  proceeds 
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6.  Scene  60:  Recon  Element  Advances 


Location 

•  Control  point  1 100m  from  beach  landing  site 
Description 

•  Recon/security  AAAV  travels  to  the  Line  of  Departure  (500  m  from  the  beach 
landing  site) 

Purpose 

•  Insert  scout  swimmers  for  reconnaissance  of  surf  and  beach 

•  Command  and  covering  elements  wait  at  their  current  location 


Storyboard 


Photo 


3D  Screen  Shot 


7.  Scene  70:  Scout -Swimmers 

Location 

•  Line  of  Departure  500m  from  the  beach  landing  site 
Description 

•  Team  of  six  to  eight  scout- swimmers  from  the  recon/security  element 
enter  the  water 

Purpose 

•  Ensure  that  beach  landing  site  and  water  approaches  are  clear  of  hazards 


Storyboard 


Photo 
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3D  Screen  Shot 


8.  Scene  80:  Recon  Complete 

Location 


•  Line  of  Departure  500m  from  the  beach  landing  site 
Description 

•  Scout- swimmers  signal  the  raid  force  to  land  using  a  green  directional 
chemlight  (only  visible  to  the  raid  force  still  at  sea) 

Purpose 

•  This  is  the  planned  signal  that  recon  is  complete  and  it  is  OK  to  land 


9.  Scene  90:  Raid  Force  Regroups  at  Line  of  Departure 


Location 

•  Line  of  Departure  (LOD)  500m  from  the  beach  landing  site 
Description 

•  Command  and  covering  elements  join  the  recon/security  element  at  LOD 
Purpose 

•  Raid  force  will  cross  Line  of  Departure  together 

•  Raid  force  will  cross  surf  zone  on  line  in  one  wave 


Storyboard 


Photo 


3D  Screen  Shot 
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10.  Scene  100:  Beach  Landing  Site 

Location: 


•  Red  Beach,  Camp  Pendleton  California 
Description: 

•  Raid  force  crosses  surf  zone  and  lands  at  beach  landing  site 
Purpose: 

•  Raid  force  reaches  the  beach  landing  site 

•  Drive  inland  to  disembark  the  Marines 

•  Marine  squads  carry  out  the  rest  of  the  mission 


Storyboard 


Photo 


3D  Screen  Shot 


D.  SUMMARY 

This  chapter  describes  the  methodology  used  to  arrive  at  the  end  goal  of 
generating  the  3D  amphibious -raid.  In  order  to  keep  the  scenario  realistic,  yet  remain 
simple  at  the  same  time,  a  number  of  assumptions  and  limitations  are  imposed.  In  order 
to  validate  the  use  of  future  platforms  such  as  the  San  Antonio  class  LPD  and  the  AAAV, 
it  was  assumed  that  both  platforms  are  fielded  and  in  use  throughout  the  fleet.  Further 
limitations  to  ensure  scenario  simplicity  include  lack  of  enemy  contact,  no  representation 
of  individual  Marines,  and  minimal  overall  numbers  of  AAAVs,  ships  and  helicopters.  In 
order  to  get  a  visual  perception  of  the  methodology  used,  the  chapter  concludes  with  a 
demonstration  of  how  the  text  description,  storyboard,  photo  and  3D  screen  shot  all  work 
in  parallel  to  embody  the  exact  same  tactical  scene. 
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vm.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  INTRODUCTION 

This  chapter  presents  conclusions  drawn  from  the  authoring  and  visualization 
work  completed  by  this  thesis.  Recommendations  for  future  work  that  benefit  or  add 
value  to  the  research  of  this  thesis  are  also  presented. 

B.  CONCLUSIONS 

Automatic  generation  of  an  operation  order  into  a  3D  virtual  battlespace  capable 
of  displaying  an  amphibious -raid  is  feasible.  The  storyboarding  technique  is  an  effective 
way  to  generate  a  rich  scenario  and  capture  the  elements  that  are  considered  vital  to 
battlespace  visualization.  While  the  final  step  of  automatic  scene  generation  did  not 
come  to  fruition  for  this  thesis  due  to  the  need  to  complete  a  more  robust  XML  schema 
than  was  available  from  the  MTF2XML  Converter,  the  Mark  Murray  and  Jason  Quigley 
thesis  has  shown  that  it  can  be  done.  It  can’t  be  stressed  enough  that  XML  is  the  “glue” 
that  makes  this  all  possible.  With  the  operation  order  format  tags  that  the  MTF2XML 
Converter  provides,  the  Generic  Hub  schema  that  defines  consistent  semantic  tags  for  the 
usable  information  within  the  GENTEXT  sectio  ns  of  the  order,  and  a  stylesheet  that 
translates  this  information  into  VRML,  only  the  number  of  3D  models  available  bound 
the  visualization  possibilities.  While  work  is  still  necessary,  this  tool  will  prove 
invaluable  in  operations  planning  efforts. 

C.  RECOMMENDATIONS  FOR  FUTURE  WORK 
1.  Standardized  Operation  Orders 

While  it  can  be  said  that  operation  orders  are  currently  standardized,  based  on  the 

limitations  of  operation  orders  discussed  in  Chapter  III,  I  would  argue  that  they  are  not 
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truly  standardized.  In  order  to  have  one  schema  or  document  type  definition  to  define  tag 
sets  that  are  valid  across  all  services  (and  within  services),  required  information,  terms, 
and  acronyms  are  going  to  have  to  be  common  for  everyone.  Ultimately,  this  would  need 
to  extend  to  annexes,  SOPs,  and  other  materials  that  may  be  referenced.  While  the 
Generic  Hub  is  just  a  database,  the  concepts  it  employs  should  be  enforced  with  regards 
to  writing  operation  orders.  Whereas  the  Generic  Hub  data  definitions  are  agreed  upon 
by  the  US  and  NATO,  the  US  military  should  develop  an  agreed  upon  standard  for 
writing  operation  orders,  conceivably  using  Generic  Hub  terminology. 

2.  Autogeneration  of  the  Amphibious  -raid  in  3D 

It  is  important  to  continue  to  work  on  an  XML  schema  and  XSL  stylesheet  that 
automatically  generates  a  3D  visualization  of  the  amphibious-raid  scenario.  While  the 
work  is  close  to  completion,  it  isn’t  there  yet.  Continued  work  and  collaboration  with  the 
XML-MTF  Development  Team,  Naval  Undersea  Warfare  Command,  and  Institute  for 
Defense  Analysis  will  ensure  a  robust  schema  is  created  that  combines  elements  of 
USMTF  and  the  Generic  Hub.  Once  the  current  scenario  can  be  autogenerated  in  3D,  it 
can  be  extended  in  functionality  and  complexity. 

3.  Expand  Scenario 

Once  it  is  shown  that  the  simple  amphibious  assault  can  be  automatically 
translated  from  an  operation  order  to  a  3D  virtual  world,  it  is  time  to  expand  the  scenario. 
In  order  to  add  the  joint  aspect  of  the  current  scenario  and  increase  the  complexity  of  the 
amphibious-raid,  3D  models  need  to  be  created  to  include  additional  ships,  tanks, 
bulldozers,  aircraft,  motor  transportation  assets,  weapons  systems,  individual  weapons, 
artillery,  and  realistic  humanoids.  It  is  essential  to  demonstrate  the  visualization  of 
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complex  scenarios  in  3D,  as  this  is  what  will  most  likely  to  be  useful  to  warfighters  using 
the  tool. 

4.  Expand  Functionality  of  the  Tool 

The  amount  of  useful  functionality  that  could  be  added  to  a  tool  as  powerful  as 
this  is  endless.  Capabilities  should  be  added  which  allow  the  user  to  control,  record,  and 
playback  the  animation  as  one  can  do  with  a  video  cassette  recorder  (VCR).  The  ability 
to  toggle  between  the  3D  world  and  a  2D  map  overlay  would  be  useful  for  planners  and 
commanders  to  see  the  “big  picture”  in  one  snapshot.  A  graphical  user  interface  (GUI) 
that  facilitates  ease  of  authoring  a  scene  would  be  a  great  value  in  decreasing  the  time  to 
learn  how  to  use  the  tool  and  the  time  to  compose  an  order.  This  GUI  could  permit  the 
author  to  drag  and  drop  entities  right  where  they  are  wanted  on  the  battlefield;  it  could 
provide  drop  down  menus  for  the  addition  of  waypoints,  calls  for  fire,  force  definitions, 
operation  timelines,  and  specific  pieces  of  3D  terrain.  In  time  this  tool  should  be  coupled 
with  current  modeling  and  simulation  systems  to  capitalize  on  their  data.  For  instance, 
the  Marine  Corps’  MAGTF  Tactical  Warfare  Simulation  (MTWS)  system  already  has  a 
repository  of  scenarios  that  have  been  previously  authored.  If  3D  scenes  could  be 
generated  directly  from  the  MTWS  system,  the  need  to  create  the  same  scenario  again 
would  be  negated. 

5.  Dynamic  3D  Terrain  Generation 

An  underlying  factor  to  the  entire  visualization  of  any  virtual  battlefield  is  the 
terrain.  While  Digital  Terrain  Elevation  Data  (DTED)  and  other  2D  sources  of  terrain 
representations  are  available  for  most  of  the  world,  3D  data  is  not.  A  tool  is  needed 
which  automatically  generates  3D  terrain  from  anywhere  in  the  world  by  simply 


providing  coordinate  (grid,  lat/long,  etc.)  input.  The  terrain  developed  for  this  scenario 
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was  built  using  the  Virtual  Reality  Toolbox.  This  tool,  developed  by  Humusoft 


(www.humusoft.com),  works  with  the  MATLAB  program  (www.mathworks.com)  to 
generate  complex  3D  shapes  from  equations.  While  a  tool  of  this  caliber  may  have 
utilities  for  the  3D  battlespace,  it  is  not  intuitive  enough  to  be  used  to  create  realistic  3D 
terrain.  More  emphasis  and  research  needs  to  be  given  to  Geo  VRML  to  bring  the 
capability  of  autogenerating  3D  terrain  from  anywhere  in  the  world  to  fruition. 
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APPENDIX  A.  ABBREVIATIONS 


2D 

Two-Dimensional 

3D 

Three-  Dimensional 

AAAV 

Advanced  Amphibious  Assault  Vehicle 

ACE 

Air  Combat  Element 

AOR 

Area  of  Responsibility 

ARG 

Amphibious  Ready  Group 

ATO 

Air  Tasking  Order 

BDU 

Battle  Dress  Uniform 

BLT 

Battalion  Landing  Team 

CAPEX 

Capabilities  Exercise 

CCIR 

Commander’s  Critical  Information 
Requirements 

CIO 

Chief  Information  Officer 

COMBAT  XXI 

Combined  Arms  Analysis  Tool  for  the  21 
Century 

COTS 

Commercial  off  the  Shelf 

CSSE 

Combat  Service  Support  Element 

DIS 

Distributed  Interactive  Simulation 

DoD 

Department  of  Defense 

DON 

Department  of  the  Navy 

DSB 

Dynamic  Scenario  Builder 

DTD 

Document  Type  Definition 

DTED 

Digital  Terrain  Elevation  Data 

DTG 

Date  Time  Group 

FSA 

Fire  Support  Area 

FSSG 

Force  Service  Support  Group 

GCE 

Ground  Combat  Element 

GeoLOD 

Geographic  Level  of  Detail 

GH 

Generic  Hub 

GIS 

Geographic  Information  Systems 

GML 

Geography  Markup  Language 

GUI 

Graphical  User  Interface 

HLA 

High  Level  Architecture 

HTML 

Hypertext  Markup  Language 

IDA 

Institute  for  Defense  Analysis 

IEEE 

Institute  of  Electrical  and  Electronic 
Engineers 

IER 

Information  Exchange  Requirements 

LC2IEDM 

Land  Command  and  Control  Information 
Exchange  Data  Model 

LCAC 

Landing  Craft  Air  Cushioned 

LOD 

Line  of  Departure 

LPD 

Landing  Platform  Dock 
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MAGTF 

Marine  Air  Ground  Task  Force 

MCCDC 

Marine  Corps  Combat  Development 
Command 

MEF 

Marine  Expeditionary  Force 

MEU 

Marine  Expeditionary  Unit 

MEU(SOC) 

Marine  Expeditionary  Unit(Special 
Operation  Capable) 

MSSG 

MEU  Service  Support  Group 

MTWS 

MAGTF  Tactical  Warfare  Simulation 

NATO 

North  Atlantic  Treaty  Organization 

NEO 

Non-combatant  Evacuation  Operation 

NFA 

No  Fire  Area 

NMCI 

Navy- Marine  Corps  Internet 

NPS 

Naval  Postgraduate  School 

NUWC 

Naval  Undersea  Warfare  Command 

OPORD 

Operation  Order 

RDF 

Resource  Description  Framework 

SAVAGE 

Scenario  Authoring  and  Visualization  for 
Advanced  Graphical  Environments 

SGML 

Standard  Generalized  Markup  Language 

SOCEX 

Special  Operation  Capabilities  Exercise 

SOP 

Standard  Operating  Procedure 

SPMAGTF 

Special  MAGTF 

TF 

Task  Force 

TFW 

Task  Force  Web 

US 

United  States 

USMC 

United  States  Marine  Corps 

USMTF 

United  States  Message  Text  Format 

VCR 

Video  Cassette  Recorder 

VRML 

Virtual  Reality  Modeling  Language 

W3C 

World  Wide  Web  Consortium 

WARNORD 

Warning  Order 

WWW 

World  Wide  Web 

X3D 

Extensible  3D 

XML 

Extensible  Markup  Language 

XML-MTF 

XML- Message  Text  Format 

XSL 

Extensible  Stylesheet  Language 

XSLT 

XSL  Transformations 
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APPENDIX  B.  JOINT -LEVEL  OPERATION  ORDER 


A.  INTRODUCTION 

This  appendix  is  the  joint- level  operation  order  for  the  amphibious-raid  written  as 
a  Word  document.  It  is  supplied  as  a  typical  initial  reference  from  which  the  unit 
operation  order  is  built.  It  is  intended  that  future  expansions  of  the  scenario  modeling 
effort  build  from  this  order.  This  order  is  not  complete,  nor  have  AOR  coordinates  been 
updated  to  reflect  the  working  scenario  since  it  was  not  important  to  do  so  in  support  of 
this  thesis.  Nevertheless,  this  operation  order  contains  sufficiently  detailed  information 
to  fully  model  an  exemplar  amphibious -raid. 

B.  JOINT  LEVEL  OPERATION  ORDER 

FM  CJTF  BLUE 
TO 

COMTHIRDFLT  N3 
CTF  ONE  SEVEN  FIVE 
CTF  ONE  SEVEN  SIX 
CTF  ONE  SEVEN  SEVEN 
CTF  ONE  SEVEN  EIGHT 
COMDESRON  TWO  ONE 
MSSG  ONE  FIVE 
ZEN/BLT  ONE  SLANT  FOUR 
ZEN/HMM  ONE  SIX  SIX 
USS  SHILOH 
USS  STETHEM 
USS  HIGGINS 
USS  BREMERTON 
COT  USS  ESSEX 
COT  USS  DENVER 
COT  USS  PEARL  HARBOR 

INFO 

BT 

UNCLAS  //N03500/ / 

EXER/XML01// 

MSGID/GENADMIN// 

SUBJ/ OPERATIONS  ORDER  FOR  AMPHIBIOUS-RAID// 

EXERCISE  EXERCISE  EXERCISE// 

REF / AWARNORD / JCS/ 0 1 1 0 0 0 Z  JAN  01// 

AMPN/REF  A  IS  JCS  WARNORD  TO  CONDUCT  AMPHIB  RAID// 

NARR/  // 

RMKS/ 

TIME  ZONE:  ZULU 
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REFERENCE:  (A)  MAP:  COMBAT  TRAINING  CHART,  CAMP  JOSEPH  H. 

PENDLETON,  DMAHTC  SERIES  V795,  EDITION  1975,  1:50,000 

(B)  MAP:  DIGITAL  TERRAIN  ELEVATION  DATA  (DTED ) 

LEVEL  1.  SERIES:  TCD ,  ITEM  DTED  128,  EDITION:  005 

(C)  MAP:  ARC  DIGITIZED  RASTER  GRAPHICS,  SERIES: 
ARC8 ,  STOCK  NO.  ARC 8  809055,  EDITION: 1. 

OPERATION  ORDER  1-01  (EXERCISE  XML01  AMPHIBIOUS-RAID) 

BASIC  ORDER 

1.  SITUATION. 

A.  GENERAL.  CONTINUED  FIGHTING  IN  KOALA  BETWEEN  SNAKE  NATIONAL 
FORCES  AND  APEAN  SEPARATISTS  HAS  RESULTED  IN  THE  DISPLACEMENT 
OF  THOUSANDS  OF  KOALAN  NON-COMBATANTS.  THE  NON-COMBANTANTS 
HAVE  ATTEMPTED  TO  FLEE  TOWARDS  THE  APEAN  AND  MONKEY  BORDERS. 
THIS  HAS  CAUSED  HEIGHTENED  TENSIONS  ALONG  THE  APEAN/KOALAN 
BORDER.  TO  SUPPORT  PEACEKEEPING  OPERATIONS  ALONG  THE  BORDER,  A 
FORWARD  OPERATING  BASE  IS  REQUIRED  IN  APE.  WHILE  THE  APEAN 
GOVERNMENT  SUPPORTS  ESTABLISHMENT  OF  THE  AIRFIELD  THE  REACTION 
OF  THE  CIVILIAN  POPULATION  IS  UNKNOWN  AND  STATE 
POLICE/MILITARY  CAPABILITIES  ARE  LIMITED.  IT  IS  THEREFORE 
NECESSARY  TO  SECURE  THE  AIRFIELD  PRIOR  TO  STAGING  AIRCRAFT. 

B.  BATTLESPACE. 

(1)  JOINT  OPERATIONS  AREA/HIGHER  COMMANDER'S  AREA  OF 
OPERATIONS:  (GIVE  BOX  WHICH  INCLUDES  AREA) 

(2)  AREA  OF  INTEREST.  APE  LITTORAL  AREA. 

(3)  AREA  OF  OPERATION 

i.  N33DEG  2 0 . 0 0MIN/W1 1 8DEG  00.00MIN 
ii.  N33DEG  0 0 . 0 0MIN/W1 1 7DEG  40.00MIN 
iii  .  N33DEG  1 0 . 0 0MIN/W1 1 7DEG  00.00MIN 
iv.  N33DEG  3 6 . 0 0MIN/W1 1 7DEG  00.00MIN 

C.  ENEMY  FORCES.  OPPOSING  FORCES  CONSIST  OF  LOCAL  ETHNIC  GROUPS 
SYMPATHETIC  TO  SNAKE  OBJECTIVES,  ISLAMIC  FUNDAMENTAL  TERRORIST 
ORGANIZATIONS  AND  DISGRUNTLED  STUDENTS  AND  WORKERS.  THE  MORE 
VIOLENT  FORCES  ARE  EQUIPPED  WITH  AK-47'S  AND  EXPLOSIVES.  THE 
LESS  ORGANIZED  GROUPS  ARE  EQUIPPED  WITH  CLUBS  AND  KNIVES.  MOST 
OF  THESE  GROUPS  HAVE  TACTICAL  AND  CELLULAR  COMMUNICATIONS 
EQUIPMENT  AND  A  STRONG  MESSENGER  SYSTEM.  MULTIPLE  INTEL 
SOURCES  INDICATE  THAT  THE  POPULATION  IS  CONCENTRATED  TO  THE 
SOUTH  IN  THE  CITY  OF  CARLSDAD . 

D.  FRIENDLY  FORCES. 

(1)  HIGHER. 

1.  MISSION.  O/O  CTF  176  CONDUCTS  AN  AMPHIBIOUS- 
RAID  INTO  THE  COUNTRY  OF  APE  TO  SECURE  THE 
APE  AIRFIELD  AND  PROVIDE  SECURITY  FOR  FOLLOW 
ON  AIR  COMBAT  ELEMENTS, 
a.  INTENT. 

i.  PURPOSE/METHOD.  THE  PURPOSE  OF 
THIS  OPERATION  IS  TO  SECURE  THE 
APE  AIRFIELD  IOT  ESTABLISH  A 
FORWARD  OPERATING  BASE.  THIS 
WILL  BE  ACCOMPLISHED  BY  AN 
AMPHIBIOUS-RAID  FROM  ARG 
SHIPPING. 

ii.  ENDSTATE.  THE  ENDSTATE  OF  THE 

OPERATION  IS  TO  HAVE  BLUE  FORCES 
IN  CONTROL  OF  THE  AIRFIELD  AND 
MEU  FORCES  RETURNED  SAFELY  TO 
ARG  SHIPPING. 
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(2)  ADJACENT.  NONE 

(3)  SUPPORTING. 

(A)  TACON  TO  CJTF  BLUE 

(1)  USS  SHILOH 

(2)  USS  STETHEM 

(3)  USS  HIGGINS 

(B)  ATTACHMENTS  AND  DETACHMENTS.  NONE 

(C)  ASSUMPTIONS.  OMITTED. 

(D)  LEGAL  CONSIDERATIONS. 

(4)  RULES  OF  ENGAGEMENT.  REFER  TO  ANNEX  C 

2.  MISSION.  I AW  REF  A,  CJTF  BLUE  CONDUCTS  A  LIMITED  AMPHIBIOUS- 
RAID  INTO  THE  COUNTRY  OF  APE  IOT  SECURE  APE  AIRFIELDIN  VIC  OF  N33DEG 
18.00MIN  LAT/  W117DEG  21.00MIN  LONG  AND  MAINTAIN  AIRFIELD  SECURITY 
UNTIL  RELIEVED  BY  CTF  175  (TF  APACHE) . 

3.  EXECUTION. 

A.  COMMANDER'S  INTENT. 

1.  PURPOSE.  THE  PURPOSE  OF  THIS  OPERATION  IS  TO  SECURE  THE 
AIRFIELD  IOT  ESTABLISH  THE  AIRFIELD  AS  A  FORWARD 
OPERATING  BASE  TO  SUPPORT  PEACEKEEPING  EFFORTS  ALONG  THE 
APEAN/KOALAN  BORDER. 

2.  METHOD.  CJTF  BLUE  WILL  CONDUCT  A  LIMITED  AMPHIBIOUS-RAID 
TO  CONTROL  THE  AIRFIELD.  ENVIRONMENT  IS  ASSUMED  TO  BE 
PERMISSIVE.  ONCE  AIRFIELD  IS  SECURED  AND  TURNED  OVER  TO 
FOLLOW  ON  FORCES  CJTF  BLUE  WILL  REEMBARK  ARG  SHIPPING 
AND  BE  PREPARED  TO  RESPOND  TO  ANY  FURTHER  TASKING. 

3.  ENDSTATE.  ATF  OBJECTIVE  A  SECURED  AND  CONTROLLED  BY  CTF 
175.  MEUFORCES  REEMBARKED  ABOARD  ARG  SHIPPING. 

B.  CONCEPT  OF  OPERATIONS. 

1.  SCHEME  OF  MANEUVER. 

i.  PHASE  I.  PRE -ASSAULT  OPERATIONS  (D-2  TO  D-DAY). 

CTF  176  CONDUCTS  AERIAL  RECONNAISSANCE  WITH  COBRA 
HELOS  IOT  DEVELOP  THE  SITUATION  AND  PROVIDE  BLS  ON 
D-DAY  FOR  SURFACE  ASSAULT  FORCES. 

1.  ENDSTATE.  POSITIVE  ID  OF  BLS  AND  OPPOSING 
FORCES . 

ii.  PHASE  II.  ASSAULT  (D-DAY  TO  D+l).  AT  H-HR  ON  D- 
DAY,  CTF  176  CONDUCTS  AN  AAAV  RAID  SUPPORTED  BY 
HELIBORNE  RECON  ELEMENTS  ACROSS  DESIGNATED 
BEACHES.  AAAV  CONDUCTS  VEHICLE  PATROL  TO  AIRFIELD 
SUPPORTED  BY  HELOS.  GCE  SECURES  AIRFIELD. 

1.  ENDSTATE.  AIRFIELD  SECURED,  CONTROL  OF 
AIRFIELD  ESTABLISHED.  ACE  REMAINS  AFLOAT, 
iii  .  PHASE  III.  FOLLOW  ON  FORCES  OPERATIONS  (D  +  l  TO 
COMPLETION) .  CTF  176  MAINTAINS  AIRFIELD  SECURE, 
RECEIVES  CTF  175  AIRCRAFT. 

1.  ENDSTATE.  SUCCESSFUL  RECEIPT  OF  CTF 
1 7 5AIRCRAFT  AND  PERSONNEL. 

iv.  PHASE  IV.  WITHDRAWAL.  CTF  176  CONDUCTS  AMPHIBIOUS 
WITHDRAWAL  FROM  AIRFIELD  ACROSS  THE  BEACH  TO  ARG 
SHIPPING. 

1.  ENDSTATE.  ALL  FORCES  RECOVERED  ABOARD  ARG 
SHIPPING. 

2.  FIRE  SUPPORT  PLAN.  REFER  TO  ANNEX  C 
(OPERATIONS) . 

C.  TASKS 

a.  COMMAND  ELEMENT  R&S.  NONE 

b.  FCE .  NONE 
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c.  GCE . 

i.  PHASE  I.  PRE-ASSAULT  OPERATIONS 

1.  SUPPORTING  EFFORT 

ii.  PHASE  II.  ASSAULT  OPERATIONS 

1 .  MAIN  EFFORT 

2.  ON  D-DAY  AT  H-HOUR,  CONDUCT  AN  AMPHIBIOUS- 
RAID  OVER  DESIGNATED  BEACHES. 

3.  SEIZE  ATF  OBJECTIVE  A 

4.  MAINTAIN  SECURITY 
iii  .  PHASE  III.  FOFO 

1.  SUPPORTING  EFFORT 

2.  CONDUCT  SECURITY  OPERATIONS 

3.  RECEIVE  CTF  175 

iv.  PHASE  IV.  WITHDRAWAL 

1.  O/O,  RECOVER  ABOARD  ARG  SHIPPING 

d.  ACE 

i.  PHASE  I.  PRE-ASSAULT  OPERATIONS 

1 .  MAIN  EFFORT 

2.  PROVIDE  VISUAL  RECONNAISSANCE 

3.  IDENTIFY  BLS  AND  PRIMARY  INGRESS/EGRESS 
ROUTES 

ii.  PHASE  II.  ASSAULT  OPERATIONS 

1.  SUPPORTING  EFFORT 

2.  PROVIDE  RWCAS  RAID  SUPPORT  FOR  MAIN  EFFORT 

3.  PROVIDE  C2  SUPPORT  FOR  COMM  RELAY  WITH  THE 
MAIN  EFFORT 

4.  PROVIDE  R&S  SUPPORT  FOR  GCE  DURING  INGRESS 
TO  ATF  OBJECTIVE  A 

iii.  PHASE  III.  FOFO 

1.  SUPPORTING  EFFORT 

2.  PROVIDE  ON-CALL  CAS  AND  R&S  SUPPORT 

iv.  PHASE  IV.  WITHDRAWAL 

1.  PROVIDE  RWCAS  AND  VEHICLE  ESCORT  IN  SUPPORT 

OF  THE  AMPHIBIOUS  WITHDRAWAL 

2.  PROVIDE  ASSAULT  SUPPORT  IN  SUPPORT  OF  THE 
AMP HIBIOIUS  WITHDRAWAL 

e.  CSSE 

i.  PHASE  I.  PRE-ASSAULT  OPERATIONS 

1.  SUPPORTING  EFFORT 

2.  CONDUCT  MAINTENANCE  ON  MEU  ASSETS  AS 
REQUIRED 

3.  PROVIDE  SEA  BASED  SUSTAINMENT  TO  THE  MAIN 
EFFORT  AS  REQUIRED 

4 .  ASSUME  REAR  AREA  COMMANDER 
ii.  PHASE  II.  ASSAULT  OPERATIONS 

1.  SUPPORTING  EFFORT 

2.  ESTABLISH  AND  CONDUCT  LFSP  OPERATIONS  AT 
DESIGNATED  RAID  BEACHES 

iii.  PHASE  III.  FOFO 

1 .  MAIN  EFFORT 

2.  CONTINUE  TO  CONDUCT  LFSP  OPERATIONS  AT 
DESIGNATED  RAID  BEACHES 

3.  FORM  A  MCSS  DETACHMENT  AND  PROVIDE 
SUSTAINMENT  TO  SUPPORTING  EFFORTS  AS 
REQUIRED 

4.  ACCEPT  TACON  OF  GCE  SECURITY  FORCES 
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5.  BPT  MOVE  ELEMENTS  OF  THE  SUPPORTING  EFFORTS 
AS  REQUIRED 

6.  BPT  PROVIDE  MAINTENANCE  CONTACT  TEAMS  IN 
SUPPORT  OF  THE  MAIN  EFFORT 

iv.  PHASE  IV.  WITHDRAWAL 

1.  CONDUCT  LFSP  AT  DESIGNATED  BEACH  FOR 
AMPHIBIOUS  WITHDRAWAL  OF  FORCES. 

2.  ON  ORDER,  RECOVER  ABOARD  ARG  SHIPPING 

D.  RESERVE.  GCE  WILL  MAINTAIN  A  MOBILE  RESERVE  ON  SHIP 

E.  COMMANDERS  CRITICAL  INFORMATION  REQUIREMENTS 

a .  PIR 

i.  TO  KNOW  THE  SIZE,  LOCATION,  AND  DISPOSITION  OF 
HOSTILE  FACTIONS  IVO  THE  BLS ,  INGRESS/EGRESS 
ROUTES  AND  AIRFIELD 

ii.  TO  KNOW  ANY  OBSTRUCTIONS  OR  OBSTACLES  IVO  RAID 
BEACHES /HLZS . 

b.  FFIR 

i.  REPORT  WHEN  A  UNIT  SUSTAINS  CASUALITIES  IN 
PERSONNEL  OR  MAJOR  END  ITEMS 
ii.  REPORT  IF  ACE  READINESS  DROPS  BELOW  75  % 

C.  EEF I 

i.  CONCEAL  THE  COMM  PLAN 
ii.  CONCEAL  THE  SCHEME  OF  MANUEVER 
iii  .  CONCEAL  HLZ'S  AND  ROUTES  TO  THE  OBJECTIVE  AREA 
iv.  CONCEAL  AIR/SURFACE  INGRESS/EGRESS  ROUTES 
v.  CONCEAL  H-HOUR  AND  D-DAY 
vi  .  FORCE/COMMAND  STRUCTURE  RELATIONSHIPS 
vii  .  ROE 

F.  COORDINATING  INSTRUCTION 

a.  D-DAY  04JUL01 

b.  H-HOUR=1500Z 

C.  L-HOUR=ON  CALL 

d.  RED  BEACH  LOCATION  ( 1 1 SMG5 72 8 3 0 ) 

e.  OBJECTIVE  A:  APE  AIRFIELD  (CAMP  PENDLETON)  ( 1 1 SMG67 0 8 4 5 ) 

4 .  ADMINSTRATION  AND  LOGISTICS 

A.  PERSONNEL  OMITTED 

B.  LOGISTICS  SEE  CSSE  OPORDER 

C.  PUBLIC  AFFAIRS  OMITTED 

D.  CIVIL  AFFAIRS 

a.  REQUESTS  FOR  POLITICAL  ASYLUM  WILL  NOT  BE  GRANTED 

E.  METEOROLOGICAL  AND  OCEANOGRAPHIC  SERVICES  METOC  UPDATES  WILL 
BE  PROVIDED  DAILY 

F.  GEOSPATIAL  INFORMATION  AND  SERVICES  OMITTED 

G.  MEDICAL  SERVICES  SEE  CSSE  OPORDER 

5 .  COMMAND  AND  SIGNAL 

A.  COMMAND  RELATIONSHIPS 

B.  COMMAND  POSTS  AND  HEADQUARTERS 

C.  SUCCESSION  TO  COMMAND 

D.  SIGNAL.  REFER  TO  OPTASK  COMMS  MESSAGE.// 

BT 

#1234 

NNNN 
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APPENDIX  C.  ANNEX  C  FOR  AMPHIBIOUS -RAID 


A.  INTRODUCTION 

This  is  Annex  C  to  the  joint  operation  order.  It  is  intended  to  show  that  much 
information  comes  from  sources  outside  the  physical  operation  order.  It  may  be  used  as  a 
tool  for  future  modeling  and  scenario  development  related  to  the  efforts  of  this  thesis. 

This  annex  is  not  complete,  nor  have  FSA  and  NFA  coordinates  been  updated  to  reflect 
the  working  scenario,  as  it  was  not  important  to  do  so  in  support  of  this  thesis. 
Nevertheless,  sufficient  detail  is  included  to  accurately  model  an  exemplar  amphibious - 
raid  along  with  supporting  ship  and  aircraft  operations. 

B.  ANNEX  C 

FM  CTF  ONE  SEVEN  SIX 
TO  MSSG  ONE  FIVE 
ZEN/BLT  ONE  SLANT  FOUR 
ZEN/HMM  ONE  SIX  SIX 
INFO  CJTF  BLUE 
COMTHIRDFLT  N3 
COMDESRON  TWO  ONE 
CTF  ONE  SEVEN  FIVE 
CTF  ONE  SEVEN  SEVEN 
CTF  ONE  SEVEN  EIGHT 
USS  SHILOH 
USS  STETHEM 
USS  HIGGINS 
USS  BREMERTON 
COT  USS  ESSEX 
COT  USS  DENVER 
COT  USS  PEARL  HARBOR 
BT 

UNCLAS  //N03500// 

EXER/XML01// 

MSGID/GENADMIN// 

SUBJ/ OPERATIONS  ANNEX  FOR  AMPHIBIOUS-RAID// 

EXERCISE  EXERCISE  EXERCISE// 

REF / A/WARNORD/ CJTF  BLUE/011000Z  JAN  01// 

AMPN/REF  A  IS  CJTF  BLUE  WARNORD  TO  CONDUCT  AMPHIB  RAID// 

NARR/ 

RMKS/ 

TIME  ZONE:  ZULU 

REFERENCE:  (A)  MAP:  COMBAT  TRAINING  CHART,  CAMP  JOSEPH  H. 

PENDLETON,  DMAHTC  SERIES  V795,  EDITION  1975,  1:50,000 

(B)  OPERATION  ORDER  1-01  (EXERCISE  XML01  AMPHIBIOUS-RAID) 
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ANNEX  C  TO  OPERATION  ORDER  1-01  (EXERCISE  XML01  AMPHIBIOUS-RAID) 
OPERATIONS 

1.  GENERAL.  THIS  ANNEX  PROVIDES  GUIDANCE  FOR  THE  CONDUCT  OF 
OPERATIONS . 

A.  SITUATION.  REFER  TO  THE  BASIC  ORDER. 

B.  MISSION.  REFER  TO  THE  BASIC  ORDER. 

C.  AREA  OF  OPERATIONS.  REFER  TO  THE  BASIC  ORDER. 

2.  CONCEPT  OF  OPERATIONS.  REFER  TO  THE  BASIC  ORDER. 

3 .  CONDUCT  OF  OPERATIONS . 

A.  AVIATION  OPERATIONS. 

a.  ATO  PUBLISHED  DAILY  BY  JFACC  (CCDG-3)  VIA  CLASSIFIED 
MESSAGE  TRAFFIC 

b.  ACO  PUBLISHED  DTG  021640Z  DEC  00  VIA  UNCLASS  MESSAGE 
TRAFFIC . 

C.  ATTACK  AVIATION  PLANNING  GUIDANCE  FOR  D-DAY. 

i.  RWCAS :  1430Z  -  2030Z  2  X  AH-1Z  ON  STATION.  THESE 

AIRCRAFT  WILL  PROVIDE  LANDING  SUPPORT  AND 
COMMUNICATIONS  SUPPORT  FOR  THE  GCE  TO  THE  BLS . 
FURTHER  R&S  SUPPORT  WILL  BE  PROVIDED  TO  GCE  DURING 
INGRESS  TO  OBJECTIVE  A. 

d.  ATTACK  AVIATION  PLANNING  GUIDANCE  FOR  D+l. 

i  .  RWCAS : 

1.  AT  2 3 0 0 Z ,  ONE  SIMCAS  SECTION  AH-1Z  ASSUMES 
15M  ALERT,  ONE  SIMCAS  SECTION  AH-1Z  ASSUMES 
60M  ALERT.  SUBMIT  JTARS  FOR  SUPPORT. 

2.  AT  0030Z,  IF  ALERT  AIRCRAFT  HAVE  NOT  BEEN 
TASKED,  ONE  SECTION  AH-1Z  LAUNCHES  AND  IS  ON 
STATION  FROM  0030Z  TO  0200Z.  SAME  SECTION 
THEN  RTB .  ADDITIONALLY,  ONE  SECTION  AH-1Z 
ASSUMES  15M  ALERT.  SUBMIT  JTARS  FOR 
SUPPORT . 

3.  AT  02 0 0 Z ,  IF  ALERT  AIRCRAFT  HAVE  NOT  BEEN 
TASKED,  ONE  SECTION  AH-1Z  LAUNCHES  AND  IS  ON 
STATION  FROM  0200Z  TO  0330Z.  SAME  SECTION 
THEN  RTB. 

4.  AT  0330Z,  IF  ALERT  AIRCRAFT  ARE  NOT  TASKED, 
AIRCRAFT  REMAIN  ON  BOAT  AVAILABLE  FOR 
TASKING. 

e.  ALL  OTHER  AVIATION  OPERATIONS  ARE  PER  THE  BASIC  ORDER 
AND  CO,  HMM  ONE  SIX  SIX  OPERATION  ORDER. 

B.  MARITIME  PREPOSITIONING  FORCE  OPERATIONS. 

C.  INFORMATION  OPERATIONS,  COMMAND  AND  CONTROL  WARFARE. 

a.  FRIENDLY  COMMAND  AND  CONTROL  WARFARE  READINESS.  STRICT 
"NO  CLUTTER"  USES  OF  ALL  ARG/MEU  NETS  IS  CRITICAL. 
CELLULAR  PHONES,  UNSECURED  NETS,  POTS  LINES  AND  SAILOR 
PHONES  WILL  NOT  BE  USED  AT  ANY  TIME  DURING  THIS 
OPERATION. 

D.  COUNTERINSURGENCY.  OMITTED. 

E.  NUCLEAR  OPERATIONS.  OMITTED. 

F.  NBC  DEFENSE  OPERATIONS.  OMITTED. 

G.  SPECIAL  OPERATIONS.  OMITTED. 

H.  TACTICAL  RECOVERY  OF  AIRCRAFT  AND  PERSONNEL.  REFER  TO  THE 
BASIC  ORDER. 

I.  RULES  OF  ENGAGEMENT. 

a.  CJCS  STANDING  AND  USPACOM  SUPPLEMENTAL  ROE  APPLY. 
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b.  OFFENSIVE  MILITARY  OPERATIONS  ARE  AUTHORIZED  IN  ATF 

OBJECTIVE  A  AGAINST  ANY  FORCES  OPPOSING  SEIZURE  OF  THESE 
OBJECTIVES . 

C.  ENTRY  INTO  THE  FOREIGN  LAND  TERRITORY,  INTERNAL  WATERS, 
AND  AIRSPACE  OF  APE  IS  AUTHORIZED. 

d.  CTF  176  IS  DELEGATED  AUTHORITY  TO  EXERCISE  NATIONAL  SELF 
DEFENSE . 

e.  USE  OF  RIOT  CONTROL  AGENTS  (RCA),  SPECIFICALLY  CS  GAS 
AND  PEPPER  SPRAY  ONLY,  IS  AUTHORIZED  TO  CONTROL 
NONCOMBATANT  INDIVIDUALS  AND  GROUPS  AS  RIOT  AND  CROWD 
CONTROL  AS  NECESSARY. 

J.  RECONNAISSANCE.  REFER  TO  R&S  CONOPS  AND  CONFIRMATION  BRIEFS. 

K.  AIR  BASE  OPERABILITY.  OMITTED. 

L.  COMBAT  CAMERA.  OMITTED. 

M.  NONCOMBATANT  EVACUATION  OPERATIONS.  REFER  TO  THE  BASIC  ORDER. 

N.  ESCAPE  AND  EVASION  OPERATIONS.  REFER  TO  R&S  CONOPS  AND 
CONFIRMATION  BRIEFS. 

O.  COUNTERATTACK.  OMITTED. 

P.  EXPLOSIVE  ORDNANCE  DISPOSAL.  OMITTED. 

Q.  AMPHIBIOUS  OPERATIONS.  REFER  TO  CTF  176  OPTASK  AMPHIB  FOR 
AMPHIBIOUS-RAID  XML01  DTG  101700Z  NOV  00  ISSUED  VIA  CLASSIFIED 
MESSAGE  TRAFFIC  AND  TO  THE  LANDING  PLAN  FOR  THIS  OPERATION. 

R.  FORCE  PROTECTION.  REFER  TO  THE  BASIC  ORDER. 

S.  REAR  AREA  OPERATIONS.  PER  CSSE  OPERATION  ORDER. 

T.  FIRE  SUPPORT. 

a.  ASSETS 

(1)  ARTILLERY  BATTERY  WILL  BE  EMPLOYED  IN  A  NON 
LETHAL  CAPACITY  DURING  THIS  OPERATION 

(2)  R/W  CAS:  2  X  AH-1Z 

(3)  USS  STETHEM,  2  X  5"54. 

b.  AIR  SUPPORT.  REFER  TO  PARAGRAPH  3. A  OF  THIS  ANNEX. 

C.  ARTILLERY  SUPPORT.  OMITTED 

d.  NAVAL  SURFACE  FIRE  SUPPORT.  USS  STETHEM  WILL  TRANSIT  TO 
FSA  1  IMMEDIATELY  PRIOR  TO  H-HOUR  AND  WILL  BE  ON-STATION 
FOR  THE  DURATION  OF  OPERATIONS  ASHORE. 

e.  FIRE  SUPPORT  COORDINATION. 

(1)  METHOD.  INITIALLY,  THE  SACC  WILL  ACT  AS  THE 
PRINCIPLE  FIRE  SUPPORT  COORDINATION  CENTER  FOR 
THE  AREA  OF  OPERATIONS.  AS  SOON  AS  THE  GCE  FSCC 
IS  ABLE  TO  CONDUCT  FIRE  SUPPORT  COORDINATION  IN 
ZONE,  RESPONSIBILITY  FOR  FIRE  SUPPORT 
COORDINATION  IN  ZONE  WILL  BE  PHASED  ASHORE. 

AFATDS  WILL  BE  THE  PRIMARY  MEANS  OF  REQUESTING 
AND  COORDINATING  SURFACE  FIRE  SUPPORT  THROUGHOUT 
THE  OPERATION.  INITIALLY,  ALL  DIGITAL  CALLS  FOR 
FIRE  WILL  ROUTE  THROUGH  THE  SACC  TO  THE  FIRING 
UNITS.  ROUTING  OF  CALLS  FOR  FIRE  WILL  TRANSITION 
TO  THE  GCE  FSCC  ONCE  IT  IS  CAPABLE  OF  PROCESSING 
MISSIONS.  ANY  VOICE  CALLS  FOR  FIRE  WILL  ROUTE 
DIRECTLY  TO  THE  FIRING  UNIT.  THE  GCE  WILL 
MONITOR,  CLEAR  AND  DECONFLICT  VOICE  FIRE  REQUESTS 
IF  ABLE.  IF  THE  GCE  IS  UNABLE,  REQUESTS  FOR 
CLEARANCE  WILL  BE  ROUTED  TO  THE  SACC  VIA  THE  LF 
FSC  2  VOICE  NET.  WHENEVER  POSSIBLE,  AND  IN  THE 
ABSENCE  OF  COMMUNICATIONS  WITH  HIGHER  AGENCIES, 
FIRE  SUPPORT  COORDINATION  WILL  BE  CONDUCTED  AT 
THE  LOWEST  POSSIBLE  LEVEL. 
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(2)  FIRE  SUPPORT  COORDINATION  MEASURES  AND 
GEOMETRY . 

1 .  FSA  ONE . 

US  MG463916 
IIS  MG521844 
US  MG491821 
IIS  MG434853 

2.  FSA  TWO. 

IIS  MG5 68784 
IIS  MG636697 
US  MG607675 
US  MG537762 

3.  ZONES  OF  ACTION.  REFER  TO  APPENDIX  18 


(OPERATIONS  OVERLAY) . 


NFA'S.  ALL  NFA'S  ARE  VALID  AS  OF  032000Z 


JAN  01.  ALL  NFA'S  AROUND  OP'S  ARE  250M  RADIUS. 


(a) 

NFA1 

1 1 SMG4  8  9008 

SS2 

(b) 

NFA2 

1 1 SMG4  8  9  9  6  9 

SS3 

(c) 

NFA3 

1 1 SMG5  8  5  8  67 

SSI 

(d) 

NFA4 

11SMG631850 

BLT3 

(e) 

NFA5 

1 1 SMG62  67  5  0 

BLT2 

(f) 

NFA6 

1 1 SMG57  0  82  8 

NSWTU 

5.  AIRSPACE  COORDINATION  MEASURES.  REFER 
TO  AIR  CONTROL  ORDER  OR  APPENDIX  18. 

f.  ATTACK  GUIDANCE.  PUBLISHED  VIA  SEPCOR. 

g.  FIRE  SUPPORT  COMMUNICATIONS.  THE  SACC  WILL  MONITOR 
THE  FOLLOWING  NETS. 


(1)  NAVAL  GUNFIRE  GROUND  SPOT. 

(2)  TAR  HR 

(3)  LF  FSC  2.  PRIMARY  VOICE  FSC  NET  AND  COF 
BACKUP . 

(4)  LF  FSC  3.  PRIMARY  DIGITAL  AFATDS  NET. 

(5)  TAD  NETS  AS  APPLICABLE. 

U.  COUNTER  MECHANIZED  PLAN.  OMITTED. 

V.  BREACHING  PLAN.  OMITTED. 

W.  OBSTACLE  PLAN.  OMITTED. 

4.  OPERATIONAL  CONSTRAINTS.  OMITTED. 

5.  COMMAND  AND  SIGNAL. 

A.  COMMAND.  REFER  TO  THE  BASIC  ORDER 

B.  SIGNAL.  REFER  TO  OPTASK  COMMS  MSG  FOR  XML01.// 


BT 

#1234 

NNNN 
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APPENDIX  D.  UNIT  OPERATION  ORDER 


A.  INTRODUCTION 

This  appendix  is  the  unit- level  operation  order  for  the  amphibious -raid  written  as 
a  word  document.  It  is  the  focus  order  from  which  follow  on  orders  were  modified  for 
purposes  of  this  thesis.  Future  additions  and  expansions  of  this  order  to  increase 
complexity  at  the  unit- level  can  build  on  this  order.  This  order  contains  enough 
information  to  understand  the  scenario  and  support  the  goals  of  this  thesis. 

B.  UNIT  OPERATION  ORDER 

FM  BLT  ONE  SLANT  FOUR 
TO  COMPANY  ALPHA 
COMPANY  BRAVO 
INFO  CJTF  BLUE 
CTF  ONE  SEVEN  SIX 
CTF  ONE  SEVEN  FIVE 
CTF  ONE  SEVEN  SEVEN 
CTF  ONE  SEVEN  EIGHT 
COMTHIRDFLT  N3 
COMDESRON  TWO  ONE 
MSSG  FIFTEEN 
ZEN/HMM  ONE  SIX  SIX 
USS  SHILOH 
USS  STETHEM 
USS  HIGGINS 
USS  BREMERTON 
COT  USS  ESSEX 
COT  USS  DENVER 
COT  USS  PEARLHARBOR 
BT 

UNCLAS/ /N03500/ / 

EXER/XML01// 

MSGID/GENADMIN// 

SUBJ/MEU  OPERATIONS  ANNEX  FOR  AMPHIBIOUS-RAID// 

EXERCISE  EXERCISE  EXERCISE// 

REF/A/OPORD/CJTF  BLUE/010100Z  JAN  01 

AMPN/REF  A  IS  CJTF  BLUE  OPORD  TO  CONDUCT  AMPHIB  RAID 
NARR/THIS  IS  MEU  OPERATIONS  ANNEX  IN  SUPPORT  OF 
XML01// 

RMKS/ 

TIME  ZONE:  ZULU 

REFERENCE : (A)  MAP:  COMBAT  TRAINING  CHART,  CAMP  JOSEPH  H. 
PENDLETON,  DMAHTC  SERIES  V795,  EDITION  1975,1:50,000 

(B)  MAP:  DIGITAL  TERRAIN  ELEVATION  DATA  (DTED )  LEVEL  1.  SERIES: 
TCD ,  ITEM  DTED  128,  EDITION:  005 

(C)  MAP:  ARC  DIGITIZED  RASTER  GRAPHICS,  SERIES:  ARC8 ,  STOCK  NO. 
ARC 8  809055,  EDITION:  1. 
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(D)  OPERATION  ORDER  1-01  (EXERCISE  XML01  AMPHIBIOUS-RAID) 

(E)  ANNEX  C  TO  OPERATION  ORDER  1-01  (EXERCISE  XML01  AMPHIBIOUS- 

RAID) 

(F)  BATTALION  ORDER  P3000  (COMBAT  SOP) 

1.  SITUATION. 

A.  GENERAL.  REFER  TO  BASIC  ORDER. 

B.  ENEMY  FORCES.  REFER  TO  BASIC  ORDER. 

C.  FRIENDLY  FORCES.  REFER  TO  BASIC  ORDER 

D.  ATTACHMENTS  AND  DETACHMENTS.  ANNEX  A  (TASK  ORGANIZATION) 

2.  MISSION.  AT  H-HOUR,  BLT  1/4  CONDUCTS  AN  AAAV  RAID  ACROSS  RED 

BEACH  AND  PROCEEDS  INLAND  TO  SEIZE  ATF  OBJECTIVE  A.  ONCE  SEIZED, 

MAINTAIN  SECURITY  OF  OBJECTIVE  UNTIL  RELIEVED  BY  TF  APACHE. 

3.  EXECUTION. 

A.  COMMANDER'S  INTENT  AND  CONCEPT  OF  OPERATIONS. 

1.  BATTALION  COMMANDERS  INTENT.  CURRENTLY 
THERE  IS  MINIMAL  THREAT  IN  OUR  ZONE. 

HOWEVER,  MY  CONCERN  LIES  IN  THE  FACT  THAT 
CIVILIAN  REACTION  IS  UNCERTAIN  AND  THERE  ARE 
GREAT  NUMBERS  OF  THEM  NEARBY.  AS  WE  ARE 
DEALING  WITH  A  CIVILIAN  GROUP,  I  SEE  THEIR 
VULNERABILITY  AS  RESPONSIVENESS  AND  LACK  OF 
TRAINING.  I  INTEND  TO  EXPLOIT  THIS  BY 
LANDING  EARLY  IN  THE  MORNING  AN  MOVING  TO 
THE  OBJECTIVE  QUICKLY  BEFORE  THE  GENERAL 
POPULACE  IS  AWAKE. 

2.  ENDSTATE.  I  SEE  OUR  ENDSTATE  AS  ATF 
OBJECTIVE  A  SECURED  &  IN  CONTROL  OF  CTF  175 
(TF  APACHE) . 

3.  CONCEPT  OF  OPERATIONS.  AT  H-HOUR,  BLT  1/4 
CONDUCTS  AN  AMPHIBIOUS-RAID  TO  SEIZE  ATF 
OBJECTIVE  A.  THREE  REINFORCED  PLATOONS  FROM 
COMPANY  A  WILL  CONDUCT  AN  AAAV  ASSAULT 
ACROSS  RED  BEACH  AND  PROCEED  INLAND  VIA 
PREDETERMINED  ROUTE  TO  SEIZE  ATF  OBJECTIVE 
A.  COMPANY  A  WILL  SECURE  THE  OBJECTIVE  AND 
REMAIN  UNTIL  RELIEVED  BY  TF  APACHE.  COMPANY 
B  IS  THE  RESERVE.  COMPANY  A  IS  THE  MAIN 
EFFORT  AND  WILL  HAVE  PRIORITY  OF  FIRES  FOR 
THE  DURATION  OF  THE  OPERATION. 

B.  TASKS 

1.  1st  PLAT  (REIN),  CO  A 

i.  AT  H-HOUR  (1500Z),  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED 
BEACH  AND  CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A. 

ii.  YOU  ARE  THE  RECONNAISSANCE  ELEMENT  AND  WILL  LOAD  IN 
AAAV  1 . 

iii  .  ONCE  YOU  REACH  THE  BLS ,  YOU  WILL  FOLLOW  IN  TRACE  OF  2nd 
AND  3rd  PLATOONS  WHILE  DRIVING  TO  ATF  OBJECTIVE  A. 

iv.  UPON  CONSOLIDATION  ON  ATF  OBJECTIVE  A,  ESTABLISH 

PERIMETER  SECURITY  IN  THE  VICINITY  OF  GRID  11SMG673842 
v.  BE  PREPARED  TO  ASSIST  WITH  THE  TURNOVER  TO  TF  APACHE. 


2.  2nd  PLAT  (REIN),  CO  A 

i.  AT  H-HOUR,  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED  BEACH  AND 
CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A. 
ii.  YOU  ARE  THE  COMMAND  ELEMENT  AND  WILL  LOAD  IN  AAAV  2. 
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iii  .  ONCE  YOU  REACH  THE  BLS ,  YOU  WILL  FOLLOW  IN  TRACE  OF  3rd 
PLATOON  WHILE  DRIVING  TO  ATF  OBJECTIVE  A. 
iv.  UPON  CONSOLIDATION  ON  ATF  OBJECTIVE  A,  ESTABLISH 

PERIMETER  SECURITY  IN  THE  VICINITY  OF  GRID  11SMG664839. 
v.  BE  PREPARED  TO  ASSIST  WITH  THE  TURNOVER  TO  TF  APACHE. 

3.  3rd  PLAT  (REIN),  CO  A 

i.  AT  H-HOUR,  CONDUCT  AN  A AAV  ASSAULT  ACROSS  RED  BEACH  AND 
CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A. 

ii.  YOU  ARE  THE  SECURITY  ELEMENT  AND  WILL  LOAD  IN  A AAV  3. 

iii.  UPON  CONSOLIDATION  ON  ATF  OBJECTIVE  A,  ESTABLISH 

PERIMETER  SECURITY  IN  THE  VICINITY  OF  GRID  11SMG676853. 

iv.  BE  PREPARED  TO  ASSIST  WITH  THE  TURNOVER  TO  TF  APACHE. 

4.  BLT  RESERVE:  CO  B 

i.  AT  H-HOUR,  YOU  ARE  ON  IMMEDIATE  ALERT  AND 
WILL  BE  PREPARED  TO  ASSUME  THE  MISSION  OF 
THE  MAIN  EFFORT. 

C.  COORDINATING  INSTRUCTIONS 

1.  D-DAY  04JUL01 

2.  H-HOUR=1500Z 

3 .  L-HOUR=ON  CALL 

4.  RED  BEACH  LOCATION  ( 1 1SMG572830 ) 

5.  ATF  OBJECTIVE  A:  APE  AIRFIELD  (CAMP  PENDLETON) 

( 1 1 SMG67  0  8  4  5) 

6.  REPORT  INCREASED  CIVIL  UNREST. 

4.  ADMINISTRATION  AND  LOGISTICS 

A.  REFER  TO  ANNEX  D  (LOGISTICS) . 

B.  PRESCRIBED  LOAD  PER  REF  D. 

5.  COMMAND  AND  SIGNAL 

A.  SIGNAL.  REFER  TO  REF  D .// 

BT 

#1234 

NNNN 
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APPENDIX  E.  USMTF  “ENHANCED”  ORDER 


A.  INTRODUCTION 

This  appendix  contains  the  same  operation  order  as  in  Appendix  D,  but  it  has 
been  entered  into  USMTF  and  “enhanced”  to  include  pertinent  amplifying  information 
(displayed  in  bold  text).  This  information  includes  call  signs,  and  an  entire  section  on 
“Timeline  and  Movement”  which  includes  a  number  of  important  times,  actions  and 
coordinates  that  are  not  normally  included  in  the  “basic”  operation  order.  In  order  to  add 
this  additional  information,  normal  operation  order  writing  criteria  were  slightly 
modified. 

B.  USMTF  ORDER 

UNCLAS 

EXER/XML01// 

MSGID/ ORDER/ BLT  ONE  SLANT  FOUR// 

ORDTYP / TASKORD /-/ / 

TIMEZONE/Z// 

ORDREF /WARNORD /C JTF  BLUE  ..- 

// 


GENTEXT/ SITUATION/ 

A.  GENERAL.  REFER  TO  BASIC  ORDER 

B.  ENEMY  FORCES.  REFER  TO  BASIC  ORDER 

C.  FRIENDLY  FORCES.  REFER  TO  BASIC  ORDER 

D.  ATTACHMENTS  AND  DETACHMENTS.  ANNEX  A  (TASK 
ORGANIZATION) // 

GENTEXT /MI SS ION/AT  H-HOUR,  BLT  1/4  CONDUCTS  AN  AAAV  RAID  ACROSS 
RED  BEACH  AND  PROCEEDS  INLAND  TO  SEIZE  ATF  OBJECTIVE  A.  ONCE 
SEIZED,  MAINTAIN  SECURITY  OF  OBJECTIVE  UNTIL  RELIEVED  BY  TF 
APACHE . // 

GENT EXT /EXE CUT I ON /A .  COMMANDER'S  INTENT  AND  CONCEPT  OF 
OPERATIONS . 

1.  BATTALION  COMMANDERS  INTENT.  CURRENTLY  THERE  IS  MINIMAL 
THREAT  IN  OUR  ZONE.  HOWEVER,  MY  CONCERN  LIES  IN  THE  FACT  THAT 
CIVILIAN  REACTION  IS  UNCERTAIN  AND  THERE  ARE  GREAT  NUMBERS  OF 
THEM  NEARBY.  AS  WE  ARE  DEALING  WITH  A  CIVILIAN  GROUP,  I  SEE  THEIR 
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VULNERABILITY  AS  RESPONSIVENESS  AND  LACK  OF  TRAINING.  I  INTEND 
TO  EXPLOIT  THIS  BY  LANDING  EARLY  IN  THE  MORNING  AND  MOVING  TO  THE 
OBJECTIVE  QUICKLY  BEFORE  THE  GENERAL  POPULOUS  IS  AWAKE. 

2.  ENDSTATE.  I  SEE  OUR  ENDSTATE  AS  ATF  OBJECTIVE  A  SECURED 
&  IN  CONTROL  OF  CTF  175  (TF  APACHE) . 

3.  CONCEPT  OF  OPERATIONS.  AT  H-HOUR,  BLT  1/4  CONDUCTS  AN 
AMPHIBIOUS-RAID  TO  SEIZE  ATF  OBJECTIVE  A.  THREE  REINFORCED 
PLATOONS  FROM  COMPANY  A  WILL  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED 
BEACH  AND  PROCEED  INLAND  VIA  PREDETERMINED  ROUTE  TO  SEIZE  ATF 
OBJECTIVE  A.  COMPANY  A  WILL  SECURE  THE  OBJECTIVE  AND  REMAIN 
UNTIL  RELIEVED  BY  TF  APACHE.  COMPANY  B  IS  THE  RESERVE.  COMPANY  A 
IS  THE  MAIN  EFFORT  AND  WILL  HAVE  PRIORITY  OF  FIRES  FOR  THE 
DURATION  OF  THE  OPERATION. 

B .  TASKS 

1.  ORGANIZATION 

A.  AAAV  COMPANY 

1.  AAAV1 

A.  CALL  SIGN  -  BLUE  DEVIL 

2 .  AAAV  2 

A.  CALL  SIGN  -  NITTANY  LION 

3.  AAAV  3 

A.  CALL  SIGN  -  HUSKY 

2.  1ST  PLAT (REIN),  CO  A 

A.  AT  H-HOUR  (1500Z),  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED 
BEACH  AND  CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A  PER  GUIDANCE 
IN  SECTION  6  OF  THIS  ORDER. 

B.  PER  GUIDANCE  IN  SECTION  6  OF  THIS  ORDER,  WITHDRAW  TO  ARG 
SHIPPING  AFTER  TF  APACHE  ASSUMES  CONTROL  OF  THE  AIRFIELD. 

C.  YOU  ARE  THE  RECONNAISSANCE  ELEMENT  AND  WILL  LOAD  IN  AAAV 

1  . 

3.  2ND  PLAT (REIN),  CO  A 

A.  AT  H-HOUR,  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED  BEACH  AND 
CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A  PER  GUIDANCE  IN  SECTION 
6  OF  THIS  ORDER. 

B.  PER  GUIDANCE  IN  SECTION  6  OF  THIS  ORDER,  WITHDRAW  TO  ARG 
SHIPPING  AFTER  TF  APACHE  ASSUMES  CONTROL  OF  THE  AIRFIELD. 

C.  YOU  ARE  THE  COMMAND  ELEMENT  AND  WILL  LOAD  IN  AAAV  2. 

4.  3RD  PLAT (REIN),  CO  A 

A.  AT  H-HOUR,  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED  BEACH  AND 
CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A  PER  GUIDANCE  IN  SECTION 
6  OF  THIS  ORDER. 

B.  PER  GUIDANCE  IN  SECTION  6  OF  THIS  ORDER,  WITHDRAW  TO  ARG 
SHIPPING  AFTER  TF  APACHE  ASSUMES  CONTROL  OF  THE  AIRFIELD. 

C.  YOU  ARE  THE  SECURITY  ELEMENT  AND  WILL  LOAD  IN  AAAV  3. 

5.  BLT  RESERVE:  CO  B 

A.  AT  H-HOUR,  YOU  ARE  ON  IMMEDIATE  ALERT  AND  WILL  BE  PREPARED 
TO  ASSUME  THE  MISSION  OF  THE  MAIN  EFFORT. 

6.  TIMELINE  AND  MOVEMENT 

A.  DEPART  SHIP  AT  H-HOUR  (INSERTION) 

1.  START  TIME:  041500ZJUL01 

2.  START  LOCATION:  LAT  N33DEG11 . OOMIN  LONG  W117DEG35 . OOMIN 

3.  END  TIME:  041800ZJUL01 

4.  END  LOCATION:  LAT  N33DEG14 . 9MIN  LONG  W117DEG25 . 7MIN 

B.  TRANSIT  TO  OBJECTIVE  AREA  (INFIL) 

1.  START  TIME : 041801Z JUL01 

2.  START  LOCATION:  LAT  N33DEG14 . 9MIN  LONG  W117DEG25 . 7MIN 

3.  WAYPOINTS: 
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A.  LAT  N33DEG15 . 538MIN  LONG  W117DEG24 . 875MIN 

B.  LAT  N33DEG13 . 976MIN  LONG  W117DEG23 . 328MIN 

C.  LAT  N33DEG17 . 274MIN  LONG  W117DEG22 . 241MIN 

4.  END  TIME:  042100ZJUL01 

5.  END  LOCATION:  LAT  N33DEG17 . 885MIN  LONG  W117DEG21 . 144MIN 

C.  ACTIONS  AT  OBJECTIVE 

A.  START  TIME:  042101ZJUL01 

B.  END  TIME:  050300ZJUL01 

1.  AAAV1 

A.  LOCATION:  LAT  N33DEG17 . 885MIN  LONG  W117DEG21 . 144MIN 

B.  ROLE:  C2  AND  SECURITY 

2 .  AAAV2 

A.  LOCATION:  LAT  N33DEG17 . 744MIN  LONG  W117DEG2 1 . 722MIN 

B.  ROLE:  SECURITY 

3.  AAAV3 

A.  LOCATION:  LAT  N33DEG18 . 419MIN  LONG  W117DEG20 . 919MIN 

B.  ROLE:  SECURITY 

D.  EXFIL 

1.  START  TIME:  050301ZJUL01 

2.  START  LOCATION:  LAT  N33DEG17 . 885MIN  LONG 
W117DEG21 . 144MIN 

3.  WAYPOINTS: 

A.  LAT  N33DEG17 . 274MIN  LONG  W117DEG22 . 241MIN 

B.  LAT  N33DEG13 . 976MIN  LONG  W117DEG23 . 328MIN 

C.  LAT  N33DEG15 . 538MIN  LONG  W117DEG24 . 875MIN 

4.  END  TIME:  050500ZJUL01 

5.  END  LOCATION:  LAT  N33DEG14 . 9MIN  LONG  W117DEG25 . 7MIN 

E .  EXTRACTION 

1.  START  TIME:  050501ZJUL01 

2.  START  LOCATION:  LAT  N33DEG14 . 9MIN  LONG  W117DEG25 . 7MIN 

3.  END  TIME:  050701ZJUL01 

4.  END  LOCATION:  LAT  N33DEG11 . OOMIN  LONG  W117DEG35 . OOMIN 

C.  COORDINATING  INSTRUCTIONS 

1.  D-DAY  04JUL01 

2.  H-HOUR=1500Z 

3 .  L-HOUR=ON  CALL 

4.  RED  BEACH  LOCATION  ( 1 1SMG572830 ) 

5.  ATF  OBJECTIVE  A:  APE  AIRFIELD  (CAMP  PENDLETON) 

( 1 1 SMG67  0  8  4  5) 

6.  REPORT  INCREASED  CIVIL  UNREST.// 

GENT EXT / AUTHENTICATION/MG  PULLER 
OFFICIAL : 

(ORIGINAL  SIGNED) 

DAILY  OPSOFF// 

ANNEXE S/ANXNO: C/OPERATION  ANNEX// 

AKNLDG/YES/ / 
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APPENDIX  F.  XML-MTF  ORDER 


A.  INTRODUCTION 

This  appendix  takes  the  previous  USMTF  order  and  runs  it  through  a  MTF2XML 
conversion  tool.  The  outcome  is  a  converted  USMTF  to  XML-MTF  message.  By 
looking  at  the  GENTEXT  sections,  it  is  apparent  that  there  are  insufficient  tags  to  capture 
any  useful  information  since  each  section  is  lumped  into  a  gigantic  element  tag.  This  is 
why  it  is  important  to  continue  to  develop  XML  schemas  that  identify  and  capture  the 
critical  information. 

B.  XMUMTF  ORDER 

<?xml  version  =  "1.0"  ?> 

-  <order> 

-  <exercise_identification  setid  ="EXER"  > 

<exercise_nickname  >XML01  </exercise_nickname  > 

</exercise_identification  > 

-  <messageJdentification  setid  ="MSGID"> 

<message_text_format_identifier>ORDER</message_text_form 

at_identifier> 

<originator>BLT  ONE  SLANT  FOUR</originator> 

</message_identification  > 

-  <type_of_order  setid  ="ORDTYP"> 

<type_of_plan_order>TASKORD</type_of_plan_order> 

<order_originator_and_or_number/> 

</type_of_order> 

-  <time_zone  setid  =  TIMEZONE  "> 

<time_zone_zulu  >Z  </time_zone_zulu  > 

</time_zone> 

-  <order_reference  setid  ="ORDREF"> 

<type_of_plan_order>WARNORD</type_of_plan_order> 

-  <order_originator_and_or_number> 

<military_command_authority>CJTF 

BLUE</military_command_authority> 

<two_character_space_filler>..  </two_character_space_filler> 
<operation_order_number>-  </operation_order_number> 
</order_originator_and_or_number> 

</o  rd  e  r_ref  e  re  n  ce  > 

-  <general_text_information  setid  ="GENTEXT" > 

<gentext_text_indicator>SITUATION</gentext_text_indicator> 
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<free_text  xml:space="preserve">A.  GENERAL.  REFER  TO 
BASIC  ORDER  B.  ENEMY  FORCES.  REFER  TO  BASIC  ORDER 
C.  FRIENDLY  FORCES.  REFER  TO  BASIC  ORDER  D. 
ATTACHMENTS  AND  DETACHMENTS.  ANNEX  A  (TASK 
ORGANIZATION)  </free_text  > 

</general_text_information  > 

<general_text_information  setid  ="GENTEXT" > 

<gentext_textJndicator>MISSION</gentext_text_indicator> 
<free_text  xml :space="preserve">AT  H-HOUR,  BLT  1/4 
CONDUCTS  AN  AAAV  RAID  ACROSS  RED  BEACH  AND 
PROCEEDS  INLAND  TO  SEIZE  ATF  OBJECTIVE  A.  ONCE 
SEIZED,  MAINTAIN  SECURITY  OF  OBJECTIVE  UNTIL 
RELIEVED  BY  TF  APACHE.  </free_text  > 
</general_text_information  > 

<general_text_information  setid  ="GENTEXT" > 

<gentext_text_indicator>EXECUTION</gentext_text_indicator> 
<free_text  xml :space="preserve">A.  COMMANDER'S  INTENT 
AND  CONCEPT  OF  OPERATIONS.  1.  BATTALION 
COMMANDERS  INTENT.  CURRENTLY  THERE  IS  MINIMAL 
THREAT  IN  OUR  ZONE.  HOWEVER,  MY  CONCERN  LIES  IN 
THE  FACT  THAT  CIVILIAN  REACTION  IS  UNCERTAIN  AND 
THERE  ARE  GREAT  NUMBERS  OF  THEM  NEARBY.  AS  WE 
ARE  DEALING  WITH  A  CIVILIAN  GROUP,  I  SEE  THEIR 
VULNERABILITY  AS  RESPONSIVENESS  AND  LACK  OF 
TRAINING.  I  INTEND  TO  EXPLOIT  THIS  BY  LANDING 
EARLY  IN  THE  MORNING  AN  MOVING  TO  THE  OBJECTIVE 
QUICKLY  BEFORE  THE  GENERAL  POPULACE  IS  AWAKE.  2. 
ENDSTATE.  I  SEE  OUR  ENDSTATE  AS  ATF  OBJECTIVE  A 
SECURED  &  IN  CONTROL  OF  CTF  175  (TF  APACHE).  3. 
CONCEPT  OF  OPERATIONS.  AT  H-HOUR,  BLT  1/4 
CONDUCTS  AN  AMPHIBIOUS-RAID  TO  SEIZE  ATF 
OBJECTIVE  A.  THREE  REINFORCED  PLATOONS  FROM 
COMPANY  A  WILL  CONDUCT  AN  AAAV  ASSAULT  ACROSS 
RED  BEACH  AND  PROCEED  INLAND  VIA  PREDETERMINED 
ROUTE  TO  SEIZE  ATF  OBJECTIVE  A.  COMPANY  A  WILL 
SECURE  THE  OBJECTIVE  AND  REMAIN  UNTIL  RELIEVED  BY 
TF  APACHE.  COMPANY  B  IS  THE  RESERVE.  COMPANY  A  IS 
THE  MAIN  EFFORT  AND  WILL  HAVE  PRIORITY  OF  FIRES 
FOR  THE  DURATION  OF  THE  OPERATION.  B.  TASKS  1. 
ORGANIZATION  A.  AAAV  COMPANY  1.  AAAV1  A.  CALL 
SIGN  -  BLUE  DEVIL  2.  AAAV  2  A.  CALL  SIGN  -  NITTANY 
LION  3.  AAAV  3  A.  CALL  SIGN  -  HUSKY  2.  1ST  PLAT(REIN), 
CO  A  A.  AT  H-HOUR  (1500Z),  CONDUCT  AN  AAAV  ASSAULT 
ACROSS  RED  BEACH  AND  CONTINUE  INLAND  TO  SEIZE 
ATF  OBJECTIVE  A  PER  GUIDANCE  IN  SECTION  6  OF  THIS 
ORDER.  B.  PER  GUIDANCE  IN  SECTION  6  OF  THIS  ORDER, 
WITHDRAW  TO  ARG  SHIPPING  AFTER  TF  APACHE 
ASSUMES  CONTROL  OF  THE  AIRFIELD.  C.  YOU  ARE  THE 
RECONNAISSANCE  ELEMENT  AND  WILL  LOAD  IN  AAAV  1. 

3.  2ND  PLAT(REIN),  CO  A  A.  AT  H-HOUR,  CONDUCT  AN 
AAAV  ASSAULT  ACROSS  RED  BEACH  AND  CONTINUE 
INLAND  TO  SEIZE  ATF  OBJECTIVE  A  PER  GUIDANCE  IN 
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SECTION  6  OF  THIS  ORDER.  B.  PER  GUIDANCE  IN 
SECTION  6  OF  THIS  ORDER,  WITHDRAW  TO  ARG 
SHIPPING  AFTER  TF  APACHE  ASSUMES  CONTROL  OF  THE 
AIRFIELD.  C.  YOU  ARE  THE  COMMAND  ELEMENT  AND  WILL 
LOAD  IN  AAAV  2.  4.  3RD  PLAT(REIN),  CO  A  A.  AT  H-HOUR, 
CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED  BEACH  AND 
CONTINUE  INLAND  TO  SEIZE  ATF  OBJECTIVE  A  PER 
GUIDANCE  IN  SECTION  6  OF  THIS  ORDER.  B.  PER 
GUIDANCE  IN  SECTION  6  OF  THIS  ORDER,  WITHDRAW  TO 
ARG  SHIPPING  AFTER  TF  APACHE  ASSUMES  CONTROL  OF 
THE  AIRFIELD.  C.  YOU  ARE  THE  SECURITY  ELEMENT  AND 
WILL  LOAD  IN  AAAV  3.  5.  BLT  RESERVE:  CO  B  A.  AT  H- 
HOUR,  YOU  ARE  ON  IMMEDIATE  ALERT  AND  WILL  BE 
PREPARED  TO  ASSUME  THE  MISSION  OF  THE  MAIN 
EFFORT.  6.  TIMELINE  AND  MOVEMENT  A.  DEPART  SHIP  AT 
H-HOUR  (INSERTION)  1.  START  TIME:  041500ZJUL01  2. 
START  LOCATION:  LAT  N33DEG1 1.00MIN  LONG 
W117DEG35.00MIN  3.  END  TIME:  041800ZJUL01  4.  END 
LOCATION:  LAT  N33DEG14.9MIN  LONG  W117DEG25.7MIN 
B.  TRANSIT  TO  OBJECTIVE  AREA  (INFIL)  1.  START 
TIME:041801ZJUL01  2.  START  LOCATION:  LAT 
N33 DEG  14.9 MIN  LONG  W117DEG25.7MIN  3.  WAYPOINTS: 
A.  LAT  N33DEG15.538MIN  LONG  W117DEG24.875MIN  B. 
LAT  N33DEG13.976MIN  LONG  W117DEG23.328MIN  C.  LAT 
N33DEG17.274MIN  LONG  W117DEG22.241MIN  4.  END 
TIME:  042100ZJUL01  5.  END  LOCATION:  LAT 
N33DEG17.885MIN  LONG  W117DEG21.144MIN  C. 
ACTIONS  AT  OBJECTIVE  A.  START  TIME:  042101ZJUL01  B. 
END  TIME:  050300ZJUL01  1.  AAAV1  A.  LOCATION:  LAT 
N33DEG17.885MIN  LONG  W117DEG21.144MIN  B.  ROLE: 

C2  AND  SECURITY  2.  AAAV 2  A.  LOCATION:  LAT 
N33DEG17.744MIN  LONG  W117DEG21.722MIN  B.  ROLE: 
SECURITY  3.  AAAV3  A.  LOCATION:  LAT  N33DEG18.419MIN 
LONG  W117DEG20.919MIN  B.  ROLE:  SECURITY  D.  EXFIL 
1.  START  TIME:  050301ZJUL01  2.  START  LOCATION:  LAT 
N33DEG17.885MIN  LONG  W117DEG21.144MIN  3. 
WAYPOINTS:  A.  LAT  N33DEG17.274MIN  LONG 
W1 17 DEG 22. 241  MIN  B.  LAT  N33DEG13.976MIN  LONG 
W117DEG23.328MIN  C.  LAT  N33DEG15.538MIN  LONG 
W117DEG24.875MIN  4.  END  TIME:  050500ZJUL01  5.  END 
LOCATION:  LAT  N33DEG14.9MIN  LONG  W117DEG25.7MIN 
E.  EXTRACTION  1.  START  TIME:  050501ZJUL01  2.  START 
LOCATION:  LAT  N33DEG14.9MIN  LONG  W117DEG25.7MIN 
3.  END  TIME:  050701ZJUL01  4.  END  LOCATION:  LAT 
N33 DEG  11. 00 MIN  LONG  W117DEG35.00MIN  C. 
COORDINATING  INSTRUCTIONS  1.  D-DAY  04JUL01  2.  H- 
HOUR=  1500Z  3.  L-HOUR=ON  CALL  4.  RED  BEACH 
LOCATION  (1 1SMG572830)  5.  ATF  OBJECTIVE  A:  APE 
AIRFIELD  (CAMP  PENDLETON)  (11SMG670845)  6. 

REPORT  INCREASED  CIVIL  UNREST.  </free_text  > 
</general_textJnformation  > 

<general_textJnforrnation  setid  ="GENTEXT" > 
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<gentext_textJndicator>AUTHENTICATION</gentext_text_in 

dicator> 

<free_text  xml:space="preserve">MG  PULLER  OFFICIAL: 
(ORIGINAL  SIGNED)  DAILY  OPSOFF </free_text  > 
</general_textJnformation  > 

-  <annex_information  setid  ="ANNEXES"> 

<annex_number>C  </annex_number> 

<annex_name  >OPERATION  ANNEX </annex_name  > 
</annex_information> 

-  <acknowledgement_requirernent  setid  ="AKNLDG"> 

<acknowledgement_requirement_indicator>YES</acknowledge 

rnent_requirementJndicator> 

</acknowledgement_requirement  > 

</order> 
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APPENDIX  G.  OPERATION  ORDER  ANNEXES 


A.  INTRODUCTION 

This  appendix  lists  the  number  and  types  of  annexes  that  can  be  referenced  in  an 
operation  order.  The  sheer  number  and  amount  of  information  contained  in  these 
annexes  add  to  the  complexity  of  “grabbing”  the  necessary  data  from  them.  References 
may  also  be  made  to  operation  overlays,  other  orders,  and  SOPs  which  compound  the 
complexity  even  further. 

B.  LIST  OF  ANNEXES 

A  -  Task  Organization 
B  -  Intelligence 
C  -  Operations 

D  -  Logistics/Combat  Service  Support 
E  -  Personnel 
F  -  Public  Affairs 
G  -  Civil  Affairs 

H  -  Meteorological  and  Oceanographic  Operations 

J  -  Command  Relationships 

K  -  Combat  Information  Systems 

L  -  Environmental  Considerations 

M  -  Geospatial  Information  and  Services 

N  -  Space  Operations 

P  -  Host  Nation  Support 

Q  -  Medical  Services 

S  -  Special  Technical  Operations 

U  -  Information  Management 

W  -  Aviation  Operations 

X  -  Execution  Checklist 

Z  -  Distribution 
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APPENDIX  H 


OPERATION  ORDER  TO  3D  METHODOLOGY 


Generic  Hub  Design  Methodology  for  Battlespace  Visualization  +  Semantics: 
DoD-wide  Autoconversion  Of  Operation  Orders  into  3D  Virtual  Environments 


Typical  Operation  Order: 
hand-crafted  “Word 


USMTF  Message: 
Modified  Operation  Order 


XM  L-MTF  free -text  Operation  Order: 

Operation  Order  GH4  Modified  XML- 

MTF 


Generic  Hub  version  4  (GH4) 
Information  Exchange  Data 
Model 


Generic  Hub  (GH4)  now 
defines  an  XML  Schema 
for  land/marilime/space 


Compatible  concepts, 
keyword-translatable 


US  and  NATO  Forces. 


Generic  Battlespace 
Schema  for  Common 
Operational/Tactical 
Picture  (COP/CTP) 


X3D/VRML  World:  Amphibious  Operation  Order 
Displayed  as  Networked,  Animated  3D  Scene! 


XSL  Style  Sheets 

XSL  Style  Sheets 

T  ransform 

T  ransform 

OPORD 

OPORD 

XM  L-MTF 

XML-MTF 

converted  to 

converted  to 

X3D/VRMT. 

RDRMS  Dn la  Fill 

GH4  Coalition 
Operational 
Context 
Database 


Global  Info  Grid 


Global  Systems 


Operational  Context  for  the  Global  Information  Grid: 
Smarter  Applications,  Agents,  Autonomous  Systems 


Points  of  Contact :  Erik  Chaum  NUWC  ChaumE@npt.nuwc.navy.mil  -  Francisco  Loaiza  ID  A  FLoaiza@  ida.org  -  Eugene  Simaitis  IDA  GSimaiti@ida.org  -  Don  Brutzman ,  Shane  Nicklaus,  Doug  Horner  NPS  brutzman@nps.navy.mil 

1 3  September  200 1 
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APPENDIX  I.  OPERATION  ORDER  SCHEMA 


A.  INTRODUCTION 

This  XML  schema  defines  the  critical  information  required  for  proper  3D  visualization  of  the  order.  It  leverages  all  of  the  tags 
from  the  XML-MTF  DTD  that  give  the  order  it’s  structure,  but  it  contains  additional  elements  and  attributes  specifically  designed  to 
capture  the  data  from  the  TASKS  section  of  the  order.  This  schema  is  authored  by  Doug  Horner  of  the  Naval  Postgraduate  School  and 
is  still  a  work  in  progress. 

B.  XML  SCHEMA 

<?xml  version  =  "1.0"  encoding  =  "UTF-8"?> 

<!--  edited  with  XML  Spy  v4.0  U  beta  3.1  build  Aug  27  2001  (http://www.xmlspy.com)  by  Doug  Horner  (Naval 
Postgraduate  School)  --> 

<xsd:schema  xmlns:xsd  ="http://www. w3.org/2001/XMLSchema  "  elementFormDefault  ="qualified"> 

<!--  Filename:  OperationOrder.xsd 
Author:  Doug  Homer 
Created:  01AUG01 
Revised:  22SEP01 

Description:  Schema  for  USMTF  2002  Order  message.  The  purpose  of  the  project  is  to  be  able  to  create  a  VRML 
scene  from  a  USMTF  message.  This  schema  is  the  tagset  that  includes  all  of  the  "Order"  message  fields  and  then  adds 
additional  tags  so  that  an  XML  document  can  "capture"  the  information  in  the  USMTF  GENTEXT  Execution  section  of  the  Order 
formatted  message  and  use  a  XSL  stylesheet  to  convert  that  to  VRML.  This  message  format  conforms  to  an  exemplar  USMC 
OPORDER  message  generated  for  KB01  exercise  --> 

<xsd:element  name  ="Order"> 

<xsd:annotation  > 

<xsd : documentation  >Root  Element  </xsd: documentation  > 

</xsd:annotation  > 

<xsd:complexType> 
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<xsd:sequence> 

<xsd:element  name  ="ExerciseIdentification"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name  ="ExerciseNickname "> 

<xsd:simpleType> 

<xsd : restriction  base  ="xsd : string " > 

<xsd:minl_ength  value="l"/> 

<xsd:maxLength  value="56"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="ExerciseMessageAdditionalIdentifier"  minOccurs  ="0"> 
<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="l"/> 

<xsd:maxLength  value="16"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

</xsd :sequence> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed  ="EXER"/> 
<xsd:attributeGroup  ref ="startTime  "/> 

<xsd :attributeGroup  ref -'endTime  "/> 

<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="actionIdNumber"  type  ="xsd:anySimpleType"  use="optional"/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="OperationIdentificationData"  minOccurs  ="0"> 
<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name  ="OperationCodeword"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="l"/> 
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<xsd:maxLength  value="32"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="PlanOriginatorAndNumber"  minOccurs  ="0"> 

<xsd:simpleType> 

<xsd : restriction  base  ="xsd : string " > 

<xsd:minLength  value="5"/> 

<xsd:maxl_ength  value="36"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="OptionNickname  "  minOccurs  ="0"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="l"/> 

<xsd:maxLength  value="23"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="SecondaryOptionNickname "  minOccurs  ="0"> 

<xsd:simpleType> 

<xsd : restriction  base  ="xsd : string " > 

<xsd:minLength  value="l"/> 

<xsd:maxl_ength  value="23"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

</xsd :sequence> 

<xsd: attribute  name="setid"  type="xsd:string"  use="required"  fixed  ="OPER"/> 

<xsd: attribute  name  ="operation Description"  type  ="xsd:anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="objectItem  Id  Number"  type  ="xsd:anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="optional"/> 

<xsd :attributeGroup  ref -'startTime  "/> 

<xsd :attributeGroup  ref -'endTime  "/> 
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<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="action  Id  Number"  type  ="xsd:anySimpleType"  use="optional"/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element  name  -'Messageldentification "> 

<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name  ="MessageTextFormatIdentifier"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="2"/> 

<xsd : maxLength  value="20"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="Originator"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="l"/> 

<xsd:maxl_ength  value="30"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

<xsd:element  name  ="MessageSerialNumber"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd:simpleContent  > 

<xsd : extension  base  ="xsd : integer" > 

<xsd: attribute  name  ="referenceldl\lumber"  type  ="xsd:anySimpleType"  use="required"/> 
</xsd:extension> 

</xsd:simpleContent> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  -'MonthName "  minOccurs  ="0"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 
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<xsd:length  value="3"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="MessageClassification"  type  ="xsd :anySimpleType"/> 
<xsd:element  name  ="MessageFormat "  type="xsd:anySimpleType"/> 

</xsd :sequence> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed  ="MSGID"/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element  name  =" Reference"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  ="SerialLetter"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:length  value="l"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="TypeOfReferenceRef"> 

<xsd:simpleType> 

<xsd :  rest riction  base  ="xsd : string " > 

<xsd:minl_ength  value="2"/> 

<xsd:maxLength  value="20"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="Originator"> 

<xsd:simpleType> 

<xsd : restriction  base  ="xsd : string " > 

<xsd:minl_ength  value="l"/> 

<xsd : maxLength  value="30"/> 

</xsd:  restriction  > 

</xsd:simpleType> 
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</xsd:element> 

<xsd: element  name  ="  DateAndOrTimeOfReferenceRef"  minOccurs  ="0"> 
<xsd:simpleType> 

<xsd : restriction  base  ="xsd : string " > 

<xsd:minLength  value="6"/> 

<xsd:maxl_ength  value="15"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name -'SerialNumberOfReference"  minOccurs  ="0"> 
<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="l"/> 

<xsd:maxLength  value="10"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name -'SpecialNotation "  minOccurs  ="0"> 

<xsd:simpleType> 

<xsd : restriction  base  ="xsd : string " > 

<xsd:length  value="5"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  =" ReferenceFieldGroup"> 

<xsd  :complexType> 

<xsd:sequence> 

<xsd:element  name  ="SicCodeOrFilingNumberRef"  minOccurs  ="0"/> 

</xsd :sequence> 

</xsd:complexType> 

</xsd:element> 

</xsd :sequence> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed  ="REF"/> 
</xsd:complexType> 

</xsd:element> 
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<xsd:element  name -'Amplification "  minOccurs  ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  ="FreeText "  minOccurs  ="0"/> 

</xsd :sequence> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed="AMPN"/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element  name  -’Narrativelnformation"  minOccurs  ="0"> 
<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  ="FreeText "  minOccurs  ="0"/> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="TypeOfOrder"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  ="TypeOfPlanOrder"> 

<xsd:simpleType> 

<xsd : restriction  base  ="xsd : string " > 

<xsd:minl_ength  value="3"/> 

<xsd:maxLength  value="16"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="OrderOriginatorAndOrl\lumber"  minOccurs  ="0"> 
<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string " > 

<xsd:minLength  value="0"/> 

<xsd:maxLength  value="59"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

</xsd:sequence> 
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<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed  ="ORDTYP"/> 
</xsd:complexType> 

</xsd:element  > 

<xsd:element  name  -’MapDatalnformation"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name  ="MapOrChartSeriesDesignator"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="3"/> 

<xsd:maxLength  value="16"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  -’MapOrChartSuffixNumber"  minOccurs  ="0"> 
<xsd:simpleType> 

<xsd : restriction  base  ="xsd : integer" > 

<xsd:totalDigits  value="2"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="MapDataInformationFieldGroup"  minOccurs  ="0"> 
<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  -’MapOrChartSheetNumber"  minOccurs  ="0"> 
<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="l"/> 

<xsd:maxLength  value="14"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  -’MapOrChartEditionNumber"  minOccurs  ="0"> 
<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 
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<xsd:minLength  value="l"/> 

<xsd:maxLength  value="6"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name -'GeodeticDatum"  minOccurs  ="0"> 

<xsd:simpleType> 

<xsd : restriction  base  ="xsd : string " > 

<xsd:minLength  value="2"/> 

<xsd:maxl_ength  value="5"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element> 

</xsd:sequence> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed  ="MAP"/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="TimeZone"> 

<xsd:complexType> 

<xsd:simpleContent  > 

<xsd : extension  base  ="xsd : string "> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed  =  "TIM  EZONE  "/> 
<xsd: attribute  name  ="timeZoneZulu "  type="xsd:string"  use="required"/> 
</xsd:extension> 

</xsd:simpleContent> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  -’OrderReference"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  ="TypeOfPlanOrder"> 

<xsd:simpleType> 
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<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="3"/> 

<xsd:maxLength  value="16"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="OrderOriginatorAndOrNumber"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  ="MilitaryCommandAuthority"> 

<xsd:complexType> 

<xsd:simpleContent  > 

<xsd : extension  base  ="xsd : string "> 

<xsd: attribute  name  ="objectItem  Id  Number"  type  ="xsd:anySimpleType"  use="required"/> 
</xsd:extension> 

</xsd:simpleContent> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="TwoCharacterSpaceFiller"/> 

<xsd:element  name  ="OperationOrderNumber"  type="xsd:string"/> 

</xsd :sequence> 

</xsd:complexType> 

</xsd:element> 

</xsd:sequence> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed="ORDREF"/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="FleadingForSegmentsOfAMessage"  minOccurs  ="0"> 
<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name  ="FleadingInformation"> 

<xsd:simpleType> 

<xsd :  restric tion  base  ="xsd : string " > 

<xsd:minLength  value="l"/> 

<xsd:maxLength  value="61"/> 
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</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

</xsd :sequence> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed  ="HEADING"/> 
</xsd:complexType> 

</xsd:element  > 

<xsd: element  name  =" Mi litaryUn ^Identification And Location_information"  minOccurs  ="0"> 
<xsd  :complexType> 

<xsd:sequence> 

<xsd:element  name  ="ColumnDefinition"/> 

<xsd:  element  name  ="  Mi  litaryllnitldentification  And  Location  Information  FieldGroup"/> 
</xsd:sequence> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="GeneralTextInformation"  minOccurs  ="0"  maxOccurs  ="unbounded"> 
<xsd:complexType> 

<xsd:complexContent  > 

<xsd: extension  base="GeneralTextInformationType"> 

<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="optional"/> 
</xsd:extension> 

</xsd:complexContent  > 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  =" DesignatedHour"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name -'HourName  "> 

<xsd:simpleType> 

<xsd : restriction  base  ="xsd : string " > 

<xsd:minLength  value="l"/> 

<xsd:maxLength  value="8"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 


127 


<xsd:element  name  ="ActionIndicator"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="3"/> 

<xsd:maxLength  value="6"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  =" DayTimeGroup"  minOccurs  ="0"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:length  value="6"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

</xsd:sequence> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed  ="HOURIS "/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="AnnexInformation"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name  -'AnnexName "> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="l"/> 

<xsd:maxLength  value="2"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="AnnexNumber"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="l"/> 

<xsd:maxl_ength  value="20"/> 
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</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

</xsd :sequence> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="required"  fixed  ="ANNEXES"/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="AcknowledgeRequirement"> 

<xsd  :complexType> 

<xsd:sequence> 

<xsd:element  name  ="AcknowledgementRequirementIndicator"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="2"/> 

<xsd:maxLength  value="3"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  ="AcknowledgementRequirementFieldGroup"  type="xsd:string"  minOccurs  ="0"/> 
</xsd :sequence> 

<xsd: attribute  name  ="setid"  type="xsd:string"  use="optional"  fixed="AKNLDG"/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element  name  =" Remarks "  minOccurs  ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  ="FreeText "/> 

</xsd :sequence> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="MessageDowngradingOrDeclassification_data"  minOccurs  ="0"> 
<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  ="SourceForClassificationDecl"> 

<xsd:simpleType> 
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<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minLength  value="l"/> 

<xsd:maxLength  value="55"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd:element  name  =" ReasonForClassification"  minOccurs  ="0"> 
<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:length  value="3"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd: element  name  ="MessageDowngradingOrDeclassificationDataFieldGroup"> 
<xsd  :complexType> 

<xsd:sequence> 

<xsd:element  name  =" DowngradeInstructionsDateDed"> 

<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:minl_ength  value="l"/> 

<xsd:maxLength  value="38"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

<xsd: element  name  ="  DowngradingOrDeclassificationExemptionCode"> 
<xsd:simpleType> 

<xsd :  restriction  base  ="xsd : string  "> 

<xsd:length  value="2"/> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element> 

</xsd :sequence> 

</xsd:complexType> 

</xsd:element> 

</xsd:sequence> 
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</xsd:complexType> 

</xsd:element> 

<!--THE  EXER  SET  PROVIDES  THE  DESIGNATED  CODE  NAME  OR  NICKNAME,  IF  THE  MESSAGE  SUPPORTS  AN 
EXERCISE.  -> 

<!--THE  OPER  SET  PROVIDES  THE  DESIGNATED  CODE  NAME  OR  NICKNAME,  IF  THE  MESSAGE  SUPPORTS  AN 
OPERATION. --> 

<!--THE  MSGID  SET  PROVIDES  THE  MESSAGE  IDENTIFICATION  AND  ORIGINATOR. -- > 

<!--THE  REF  SET  PROVIDES  BOTH  USMTF  AND  NON-USMTF  REFERENCES.  -- > 

<!--THE  ORDTYP  SET  SPECIFIES  THE  TYPE  OF  FIVE  PARAGRAPH  ORDER  BEING  SENT..-> 

<!--THE  MAP  SET  PROVIDES  THE  MAP  REFERENCES  FOR  THE  ORDER  MESSAGE. --> 

<!--THE  TIMEZONE  SET  DESIGNATES  ZULU  TIME  AS  THE  REFERENCE  FOR  THE  ORDER  MESSAGE. .--> 

<!--THE  ORDREF  SET  SPECIFIES  THE  TYPE  AND  DESIGNATION  (NUMBER  OR  LETTER)  OF  THE  BASIC  ORDER 
ADDRESSED  BY  THIS  MESSAGE. .-> 

<!--THE  HEADING/TASK  ORGANIZATION  SET  INTRODUCES  THE  SECTION  FOR  ADDRESSING  TASK  UNITS  --> 

<!--THE  HOURIS  SET  PROVIDES  THE  DESIGNATED  HOUR  FORTHE  ORDER. --> 

<!--THE  ANNEXES  SET  PROVIDES  A  LISTING  FOR  ALL  APPROPRIATE  ANNEXES  TO  THE  ORDER. --> 

<!--THE  AKNLDG  SET  PROVIDES  OPERATOR  ACKNOWLEDGEMENT  AND  NOT  COMMUNICATIONS  CENTER 
ACKNOWLEDGEMENT.--  > 

<!--THE  DECL  SET  PROVIDES  DECLASSIFICATION  OR  DOWNGRADING  INSTRUCTIONS,  IF  THE  MESSAGE  IS 
CLASSIFIED  --> 

</xsd :sequence> 

</xsd:complexType> 

</xsd:element> 

<!--  There  are  normally  5  General  Text  Information  fields,  they  are  SITUATION  |  MISSION  |  EXECUTION  |  ADMIN  AND 
LOG  |  COMMAND  AND  CONTROL  --> 

<xsd:complexT ype  name  ="GeneralTextInformationType"> 

<xsd:annotation  > 

<xsd:documentation>GENTEXT  sections  of  the  Order  message</xsd:documentation > 

</xsd:annotation  > 

<xsd :sequence> 

<xsd:element  name  ="GentextTextIndicator"  id="EXECUTION"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd:simpleContent  > 

<xsd : extension  base="xsd:string"> 

<xsd: attribute  name  ="contextId"  type="xsd:anySimpleType"  use="optional"/> 
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</xsd:extension> 

</xsd:simpleContent> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  -’FreeText"  type="xsd:string"  minOccurs  ="0"/> 

<xsd:element  name  ="CdrsIntentAndConceptOfOperations"  minOccurs  ="0"> 
<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name  =" BattalionCdrIntent"/> 

<xsd:element  name  ="EndState"/> 

<xsd:element  name  ="ConceptOfOperations"/> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name -’Tasks"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  -’Organization"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name  ="MarineExpeditionaryUnit"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element  name  =" BattalionLandingTeam"  minOccurs  ="0"> 

<xsd  :complexType> 

<xsd:sequence> 

<xsd:element  name  ="Company "  minOccurs  ="0"  maxOccurs  ="3"> 

<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name  ="Platoon "  minOccurs  ="0"  maxOccurs  ="3"> 

<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name="Squad"  minOccurs  ="0"  maxOccurs  ="2"> 

<xsd:complexType> 

<xsd: attribute  name  ="objectItemIdN umber"  type  ="xsd:anySimpleType"  use="required"/> 
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<xsd : attribute  name  ="objectTypeIdN umber"  type="xsd:anySimpleType"  use="required"/> 
<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="required"/> 

<xsd: attribute  name  ="callSign"  type  ="xsd :anySimpleType"  use="optional"/> 
</xsd:complexType> 

</xsd:element> 

</xsd :sequence> 

<xsd: attribute  name  ="objectItem  Id  Number"  type  ="xsd:anySimpleType"  use="required"/> 
<xsd: attribute  name  ="objectTypeIdl\l umber"  type  ="xsd:anySimpleType"  use="required"/> 
<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="required"/> 

<xsd: attribute  name  ="callSign"  type  ="xsd :anySimpleType"  use="optional"/> 
</xsd:complexType> 

</xsd:element> 

</xsd:sequence> 


<xsd: attribute  name  ="objectItemIdl\l umber"  type  ="xsd:anySimpleType"  use="required"/> 
<xsd: attribute  name  ="objectTypeIdN umber"  type  ="xsd:anySimpleType"  use="required"/> 
<xsd: attribute  name  ="name  "/> 

<xsd: attribute  name  ="callSign"  type  ="xsd :anySimpleType"  use="optional"/> 
</xsd:complexType> 

</xsd:element> 

</xsd :sequence> 

<xsd: attribute  name  ="objectItemIdl\l umber"  type  ="xsd:anySimpleType"  use="required"/> 
<xsd: attribute  name  ="objectTypeIdN umber"  type  ="xsd:anySimpleType"  use="required"/> 
<xsd: attribute  name  ="name  "/> 

</xsd:complexType> 

</xsd:element> 

</xsd:sequence> 

<xsd: attribute  name  ="objectItemIdN umber"  type  ="xsd:anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="objectTypeIdl\l umber"  type  ="xsd:anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="required"/> 
</xsd:complexType> 

</xsd:element> 

</xsd :sequence> 

</xsd:complexType> 

</xsd:element> 

<xsd: element  name  -'ExecutionTimelineAnd Movement "  minOccurs  ="0"> 
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<xsd  :complexType> 

<xsd:sequence> 

<xsd:element  name  -'Insertion"  maxOccurs  ="3"> 

<xsd:complexType> 

<xsd:attributeGroup  ref -'startTime  "/> 

<xsd:attributeGroup  ref =" location"/ > 

<xsd: attribute  name  ="objectItemIdN umber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="objectTypeIdN umber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="action Description"  type  ="xsd :anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="action  Id  Number"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="candidateTargetDetai II ndexN umber"  type="xsd :anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="action"  type="xsd:anySimpleType"  use="optional"/> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  -’Infiltration"  minOccurs  ="0"  maxOccurs  ="3" > 

<xsd  :complexType> 

<xsd  :attributeGroup  ref =" startTime  "/> 

<xsd:attributeGroup  ref =" location"/ > 

<xsd: attribute  name  ="objectItemIdl\l umber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="objectTypeIdN umber"  type  ="xsd:anySimpleType"  use="required"/> 

<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="action Description"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="actionIdNumber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd:  attribute  name  ="candidateTargetDetai  II  ndexN  umber"  type="xsd  :anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="action"  type="xsd:anySimpleType"  use="optional"/> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="ActionsAtTheObjective"  maxOccurs  ="3"> 

<xsd:complexType> 

<xsd:attributeGroup  ref =" startTime  "/> 

<xsd:attributeGroup  ref ="location"/> 

<xsd: attribute  name  ="objectItemIdN umber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="objectTypeIdN  umber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="optional"/> 
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<xsd : attribute  name  ="action Description"  type  ="xsd  :anySimpleType"  use="optional"/> 

<xsd:  attribute  name  ="action  Id  Number"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name="candidateTargetDetailIndexNumber"  type="xsd:anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="action"  type="xsd:anySimpleType"  use="optional"/> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name="Exfil"  minOccurs  ="0"  maxOccurs  ="3"> 

<xsd:complexType> 

<xsd :attributeGroup  ref ="startTime  "/> 

<xsd :attributeGroup  ref ="location"/> 

<xsd: attribute  name  ="objectItemIdN umber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="objectTypeIdN umber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="action Description"  type  ="xsd :anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="actionIdNumber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="candidateTargetDetailIndexNumber"  type="xsd :anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="action"  type="xsd:anySimpleType"  use="optional"/> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  -’Extraction"  maxOccurs  ="3"> 

<xsd:complexType> 

<xsd:attributeGroup  ref ="  start  Time  "/> 

<xsd:attributeGroup  ref =" location"/ > 

<xsd: attribute  name  ="objectItemIdN umber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="objectTypeIdN umber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="name  "  type  ="xsd :anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="action Description"  type  ="xsd :anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="actionIdNumber"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="candidateTargetDetai II ndexN umber"  type="xsd:anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="action"  type="xsd:anySimpleType"  use="optional"/> 

</xsd:complexType> 

</xsd:element> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element> 
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</xsd:sequence> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="CoordinatingInstructions"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd :sequence> 

<xsd:element  name="DDay"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd :attributeGroup  ref -'startTime  "/> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name="HHour"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd  :attributeGroup  ref =" startTime  "/> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name="LHour"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd:attributeGroup  ref =" startTime  "/> 

</xsd:complexType> 

</xsd:element> 

<xsd:element  name  ="MissionObjectiveLocation "  minOccurs  ="0"> 

<xsd:complexType> 

<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="optional"/> 

<xsd :attributeGroup  ref="location"/> 

<xsd: attribute  name  ="targetIdN umber"  type  ="xsd:anySimpleType"  use="optional"/> 
</xsd:complexType> 

</xsd:element> 

<xsd:element  name  =" BeachLandingSite"  minOccurs  ="0"> 

<xsd:complexType> 

<xsd: attribute  name  ="name  "  type="xsd:anySimpleType"  use="optional"/> 
<xsd:attributeGroup  ref =" location"/ > 

</xsd:complexType> 

</xsd:element> 

</xsd:sequence> 
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</xsd:complexType> 

</xsd:element> 

</xsd:sequence> 

</xsd:complexType> 

<xsd:attributeGroup  name  ="startTime  "> 

<xsd: attribute  name  ="day"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="time"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="timeZone"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="month"  type  ="xsd :anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="year"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="julianDate"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="startTimeInSecondsPerDay"  type="xsd:anySimpleType"  use="optional"/> 
</xsd:attributeGroup> 

<xsd :attributeGroup  name  ="location"> 

<xsd :attributeGroup  ref ="latitudeLongitude"/> 

<xsd:attributeGroup  ref="UTM"/> 

<xsd: attribute  name  ="locationIdNumber"  type="xsd:anySimpleType"  use="optional"/> 

<xsd:  attribute  name  ="featu  relocation  I  ndexN  umber"  type  ="xsd  :anySimpleType"  use="optional"/> 
</xsd:attributeGroup> 

<xsd:attributeGroup  name  ="latitudeLongitude"> 

<xsd: attribute  name  ="latitude"  type  ="xsd :anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="longitude"  type="xsd:anySimpleType"  use="optional"/> 
</xsd:attributeGroup> 

<xsd :attributeGroup  name  ="UTM"> 

<xsd: attribute  name  ="utmGridZoneColumn "  type  ="xsd :anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="utmGridZoneRow"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="utmlOOOOOMeterSquareColumn"  type="xsd:anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="utmlOOOOOMeterSquareRow"  type="xsd:anySimpleType"  use="optional"/> 
<xsd: attribute  name  ="utmlOMeterEasting"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="utmlOMeterl\lorthing"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="utmlOOMeterEasting"  type  ="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="utmlOOMeterl\lorthing"  type="xsd:anySimpleType"  use="optional"/> 
</xsd:attributeGroup> 

<xsd: attribute  name  ="name  "/> 

<xsd: attribute  name  ="objectItemIdNumber"/> 
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<xsd : attribute  name  ="objectTypeIdNumber"/> 

<xsd: attribute  name  ="callSign"  type  ="xsd :anySimpleType"/> 

<xsd: attribute  name  ="candidateTargetDetai II ndexN umber"  type="xsd :anySimpleType"/> 
<xsd:attributeGroup  name  ="endTime  "> 

<xsd: attribute  name  ="day"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="time "  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="timeZone"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="month"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="year"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  ="julianDate"  type="xsd:anySimpleType"  use="optional"/> 

<xsd: attribute  name  =nendTimeInSecondsPerDay "  type="xsd:anySimpleType"  use="optional"/> 
</xsd:attributeGroup> 

</xsd:schema  > 
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APPENDIX  J.  XML-MTF  OPERATION  ORDER  USIN  G  NEW  SCHEMA 


A.  INTRODUCTION 

This  Appendix  applies  the  XML-MTF  operation  order  in  Appendix  F  to  the  improved  schema.  Whereas  the  GENTEXT  in  the 
original  message  is  lumped  together  as  a  single  tag,  GENTEXT  data  in  this  message  is  extracted,  making  it  useful  for  visualization. 
This  message  will  continue  to  evolve  until  the  schema  in  Appendix  I  is  completed. 

B.  OPERATION  ORDER 

<?xml  version  =  "1.0"  encoding  =  "UTF-8"  ?> 

-  cr¬ 
edited  with  XML  Spy  v4.0  U  beta  3.1  build  Aug  27  2001  (http://www.xmlspy.com)  by  Doug  Horner  (Naval  Postgraduate  School) 

--  > 

<?xml-stylesheet  type="text/xsl"  href ="C:\Program  Files\Altova\XML  Spy  Suite\XML2XMLconversion.xsl"?> 

-  cOrder  xml  ns:  xsi="http:// www.w3.org/  2001  /XMLSchema- instance" 

xsi:nol\lamespaceSchemaLocation="C:\Program  Files \Altova\XML  Spy  Suite\ModOperationOrder.xsd"> 

-  <ExerciseIdentification  setid="EXER"  name  ="Amphibious  Raid  on  Camp  Pendleton" 

actionIdNumber="9999900000"> 

<ExerciseNickname  >XML01  </ExerciseNickname  > 

</ExerciseIdentification  > 

-  <MessageIdentification  setid  ="MSGID"> 

<MessageTextFormatIdentifier>ORDER</MessageTextFormatIdentifier> 

<Originator>JTF  167  </Originator> 

<MessageSerial Number  referenceIdNumber="5250001" >129005 </MessageSerialNumber> 

<MessageClassification  >UNCLASSIFIED</MessageClassification  > 

<MessageFormat  >USMTF  </MessageFormat  > 

</MessageIdentification  > 
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<TypeOfOrder  setid  ="ORDTYP"> 

<TypeOfPlanOrder>OPORD</TypeOfPlanOrder> 

<OrderOriginatorAndOrNumber /> 

</TypeOfOrder> 

<TimeZone  setid  ="TIMEZONE "  timeZoneZulu  ="Z"  /> 

<OrderReference  setid  ="ORDREF"> 

<TypeOfPlanOrder>OPORD</TypeOfPlanOrder> 

-  <OrderOriginatorAndOrNumber> 

<MilitaryCommand  Authority 

objectItemIdNumber="555550014">USPACCOM  </MilitaryCommandAuthority> 
<TwoCharacterSpaceFiller>..  </TwoCharacterSpaceFiller> 
<OperationOrderl\lumber>A101</OperationOrderNumber> 

</OrderOriginatorAndOrNumber> 

</OrderReference> 

<FieadingForSegmentsOfAMessage  setid  ="HEADING"> 

<HeadingInformation >TASK  ORGANIZATION</Headinglnformation> 

</FleadingForSegmentsOfAMessage> 

<GeneralTextInformation  > 

<GentextTextIndicator  contextld  ="92220001">SITUATION</GentextTextIndicator> 

<FreeText  >A.  GENERAL.  REFER  TO  BASIC  ORDER  B.  ENEMY  FORCES.  REFER  TO  BASIC  ORDER  C. 
FRIENDLY  FORCES.  REFER  TO  BASIC  ORDER  D.  ATTACHMENTS  AND  DETACHMENTS.  ANNEX  A 
(TASK  ORGANIZATION)  </FreeText  > 

</GeneralTextInformation  > 

<GeneralTextInformation  > 

<GentextTextI indicator  contextld  ="92220002">MISSION</GentextTextIndicator> 

<FreeText  >AT  H-HOUR,  BLT  1/4  CONDUCTS  AN  AAAV  RAID  ACROSS  RED  BEACH  AND  PROCEEDS 
INLAND  TO  SEIZE  ATF  OBJECTIVE  A.  ONCE  SEIZED,  MAINTAIN  SECURITY  OF  OBJECTIVE  UNTIL 
RELIEVED  BY  TF  APACHE.  </FreeText  > 

</GeneralTextInformation  > 

<GeneralTextInformation  > 

<GentextTextIndicator  contextld  ="92220003 ">EXECUTION</GentextTextIndicator> 

<FreeText  /> 

-  <CdrsIntentAndConceptOfOperations> 
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<BattalionCdrIntent>l.  BATTALION  COMMANDERS  INTENT.  CURRENTLY  THERE  IS  MINIMAL 
THREAT  IN  OUR  ZONE.  HOWEVER,  MY  CONCERN  LIES  IN  THE  FACT  THAT  CIVILIAN 
REACTION  IS  UNCERTAIN  AND  THERE  ARE  GREAT  NUMBERS  OF  THEM  NEARBY.  AS  WE  ARE 
DEALING  WITH  A  CIVILIAN  GROUP,  I  SEE  THEIR  VULNERABILITY  AS  RESPONSIVENESS  AND 
LACK  OF  TRAINING.  I  INTEND  TO  EXPLOIT  THIS  BY  LANDING  EARLY  IN  THE  MORNING  AND 
MOVING  TO  THE  OBJECTIVE  QUICKLY  BEFORE  THE  GENERAL  POPULACE  IS 
AWAKE.  </BattalionCdrIntent  > 

<EndState>2.  ENDSTATE.  I  SEE  OUR  ENDSTATE  AS  ATF  OBJECTIVE  A  SECURED  AND  IN 
CONTROL  OF  CTF  175.  </EndState> 

<ConceptOfOperations >3.  CONCEPT  OF  OPERATIONS.  AT  H-HOUR,  BLT  1/4  CONDUCTS  AN 
AMPHIBIOUS  RAID  TO  SEIZE  ATF  OBJECTIVE  A.  THREE  REINFORCED  PLATOONS  FROM 
COMPANY  A  WILL  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED  BEACH  AND  PROCEED  INLAND 
VIA  PREDETERMINED  ROUTE  TO  SEIZE  ATF  OBJECTIVE  A.  COMPANY  A  WILL  SECURE  THE 
OBJECTIVE  AND  REMAIN  UNTIL  RELIEVED  BY  TF  APACHE.  COMPANY  B  IS  THE  RESERVE. 
COMPANY  A  IS  THE  MAIN  EFFORT  AND  WILL  HAVE  PRIORITY  OF  FIRES  FOR  THE  DURATION 
OF  THE  OPERATION.  </ConceptOfOperations > 

</CdrsIntentAndConceptOfOperations> 

<Tasks  > 

-  <Organization> 

-  <MarineExpeditionaryUnit  name  ="15TH  MEU"  objectItemIdNumber="555550001" 
objectTypeIdNumber="777770001  "> 

-  <BattalionLandingTeam  name  ="BLTl/4"  objectItemIdNumber="555550002" 
objectTypeIdl\lumber="777770002"> 

-  <Company  name  ="INFANTRY  CO"  objectItemIdl\lumber=" 555550003" 

objectTypeIdl\lumber="777770003"> 

<Platoon  name  ="1ST  PLT(REIN) "  objectItemIdNumber="555550004" 
objectTypeIdNumber="777770004"  /> 

<Platoon  name  ="2ND  PLT(REIN) "  objectItemIdNumber="555550005" 
objectTypeIdNumber="777770004"  /> 

<Platoon  name  ="3RD  PLT(REIN) "  objectItemIdNumber="555550006" 
objectTypeIdNumber="777770004"  /> 

</Company  > 

-  <Company  name  =" AAAV  CO"  objectItemIdNumber="555550007" 

objectTypeIdNumber="777770003"> 
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<Platoon  name="AAAVl"  objectItemIdNumber="555550008" 
objectTypeIdNumber="777770004"  /> 

<Platoon  name="AAAV2"  objectItemIdNumber="555550009" 
objectTypeIdNumber="777770004"  /> 

<Platoon  name="AAAV3"  objectItemIdNumber="555550010" 
objectTypeIdNumber="777770004"  /> 

</Company  > 

</  Battalion  La  ndingTeam> 

</MarineExpeditionaryUnit  > 

</Organization> 

<ExecutionTimelineAndMovement  > 

insertion  name  ="Primary  Insertion  Point"  objectItemIdNumber="555550010" 

objectTypeIdNumber="777770010"  latitude="N33  11.00"  longitude="W117  35.00"  day="01" 
time  ="1500"  timeZone="Z"  month="JAN"  year="2001"  julianDate="36519" 
sta rtTi mein SecondsPerDay ="54000"  location  Id  Number="888800  01" 

featureLocationIndexNumber="111110001"  actionDescription  =" Insert  AAAV  Company  from 
the  LHD"  actionIdNumber="999990001"  candidateTargetDetailIndexNumber="1000001" 
action  ="INSERT"  /> 

<Infiltration  name  ="Primary  Infil  Route"  objectItemIdNumber="555550011" 

objectTypeIdNumber="777770011"  latitude="N33  14.9"  longitude="W117  25.7"  day="01" 
time  ="1800"  timeZone="Z"  month="JAN"  year="2001"  julianDate="36519" 
sta  rtTi  mein  SecondsPerDay ="54000"  location  Id  N  urn  ber="88880002" 

featureLocationIndexNumber="111110002"  actionDescription  ="Secure  the  BLS,  proceed  to 
the  AF"  actionIdl\lumber="999990002"  candidateTargetDetailIndexl\lumber="1000002" 
action  ="INFILT"  /> 

<ActionsAtTheObjective  name="Camp  Pendleton  Airfield"  objectItemIdNumber="555550012" 
objectTypeIdNumber="7777700012"  latitude="N33  17.88"  longitude="W117  21.44" 
day  ="01"  time  ="2100"  timeZone="Z"  month="3AN"  year="2001"  julianDate="36519" 
sta  rtTi  mein  SecondsPerDay ="54000"  location  Id  N  urn  ber="88880003" 

featureLocationIndexl\lumber="111110003"  actionDescription  ="Secure  Camp  Pendleton  AF" 
actionIdNumber="999990003"  candidateTargetDetai II ndexl\lumber="  1000003" 
action  ="SECURE"  /> 

<Exfil  name  ="Primary  Exfil  Route"  objectItemIdNumber="555550013" 

objectTypeIdNumber="777770013"  latitude="N33  17.88"  longitude="W117  21.44"  day="02" 
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time  ="0300"  timeZone="Z"  month="JAN"  year="2001"  julianDate="36519" 
sta rtTi mein SecondsPerDay ="54000"  locationIdl\lumber="88880004" 

featureLocationIndexl\lumber="111110004"  actionDescription  =" Return  from  the  Airfield  to 
the  LHD"  actionIdNumber="999990004"  candidateTargetDetailIndexNumber="1000004" 
action  ="EXFILT"  /> 

<Extraction  name  ="Primary  Extraction  Point"  objectItemIdNumber="555550014" 

objectTypeIdNumber="777770014"  latitude="N33  17.88"  longitude="W117  21.44"  day="02" 
time  ="0700"  timeZone="Z"  month="JAN"  year="2001"  julianDate="36519" 
sta  rtTi  mein  SecondsPerDay ="54000"  locationIdNumber="88880005" 

featureLocationIndexNumber="111110005"  actionDescription  ="Extract  AAAV  Company  and 
return  to  LHD"  actionIdl\lumber="999990005"  candidateTargetDetailIndexl\lumber="1000005" 
action  ="EXTRCT"  /> 

</ExecutionTimelineAndMovement  > 

</Tasks  > 

-  <CoordinatingInstructions> 

<DDay  day="01"  month="JAN"  year="2001"  /> 

<HHour  time  ="1500"  timeZone="Z"  /> 

<LHour  time  ="1800"  timeZone="Z"  /> 

<MissionObjectiveLocation  name="APE  AIRFIELD  (CAMP  PENDLETON)"  latitude=" N33  17.88" 
longitude="W117  21.44"  targetldl\lumber="6566"  /> 

<BeachLandingSite  name="Beach  Landing  Site"  latitude="N33  14.9"  longitude="W117  25.7"  /> 
</CoordinatingInstructions  > 

</GeneralTextInformation  > 

<GeneralTextInformation  > 

<GentextTextIndicator  contextld  ="92220004">ADMIN  AND  LOG</GentextTextIndicator> 

<FreeText  >REFER  TO  BASIC  ORDER</FreeText  > 

</GeneralTextInformation  > 

<GeneralTextInformation  > 

<GentextTextIndicator  contextld  ="92220005">COMMAND  AND  CONTROL</GentextTextIndicator> 
<FreeText  >REFER  TO  OPTASK  COMMS</FreeText  > 

</GeneralTextInformation  > 

<AcknowledgeRequirement  > 

<AcknowledgementRequirementIndicator>YES</AcknowledgementRequirementIndicator> 
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</AcknowledgeRequirement  > 
</Order> 
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APPENDIX  K.  GENERIC  HUB  SCHEMA 


A.  INTRODUCTION 

The  Generic  Hub  (GH)  XML  schema  defines  semantic  tags  that  attempt  to  embrace  all  possible  elements  incorporated  in  the 
database.  This  schema  is  robust  in  that  it  works  for  any  document  or  order  that  may  utilize  the  element  tags,  not  just  operation  orders. 
This  schema  is  needed  in  order  to  create  documents  that  are  compliant  and  interoperable  with  the  GH  database.  Franciso  Loaiza  and 
Eugene  Simaitis  from  the  Institute  for  Defense  Analysis  created  this  schema.  As  this  order  is  in  excess  of  160  pages,  it  is  not  included 
it  its  entirety.  Sufficient  tags  are  depicted  order  to  convey  enough  information  to  obtain  a  reasonable  appreciation  of  its  contents. 

B.  GENERIC  HUB  SCHEM  A 

<?xml  version  =  "1.0"  encoding  =  "UTF-8"  ?> 

-cr¬ 
edited  with  XML  Spy  v4.0  U  beta  3  build  Aug  24  2001  (http://www.xmlspy.com)  by  FRANCISCO  L  LOAIZA  (SED) 

--  > 

W3C  Schema  generated  by  XML  Spy  v4.0  U  beta  3  build  Aug  24  2001  (http://www.xmlspy.com) 

--  > 

-  <xsd:schema  xmlns:xsd="http://www.w3.org/2001/XMLSchema"  elementFormDefault  ="qualified"> 

-  <xsd:element  name  ="AbsolutePoint"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref="AbsolutePoint.io ngitudeCoordinate"  /> 

<xsd:element  ref =" AbsolutePoint.latitudeCoordinate"  /> 

<xsd:element  ref =' AbsolutePoint.elevationCategoryCode  /> 

<xsd:element  ref=MAbsolutePoint.id"  /> 
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<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

<xsd:element  name  ="AbsolutePoint.elevationCategoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="EAP"  /> 

<xsd:enumeration  value="LOC"  /> 

<xsd:enumeration  value="NOS"  /> 

<xsd:enumeration  value="SEA"  /> 

<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

<xsd:element  name  ="AbsolutePoint.id"  type="xsd:long"  /> 

<xsd:element  name  ="AbsolutePoint.latitudeCoordinate"  type  ="xsd:decimal"  /> 
<xsd:element  name  ="AbsolutePoint.longitudeCoordinate"  type="xsd:decimal"  /> 

<xsd:element  name  ="AbsolutePointTable "> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref="AbsolutePoint"  maxOccurs  ="unbounded"  /> 
</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

<xsd:element  name  ="Action"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref="Action.id"  /> 

<xsd:element  ref=MAction.name"  /> 

<xsd:element  ref=MAction.categoryCode"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 
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<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

<xsd:element  name  ="Action.categoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="ACTEV"  /> 

<xsd:enumeration  value="ACTTA"  /> 

<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

<xsd:element  name  ="Action.id "  type  ="xsd:long"  /> 

<xsd:element  name  ="Action. name"  type="xsd:string"  /> 

<xsd:element  name  ="ActionAircraftEmployment"> 

-  <xsd:complexType> 

-  <xsd :sequence> 

<xsd :element  ref ='  Action AircraftEmployment.terminalAttackDirectionAngle "  /> 

<xsd: element  ref ="ActionAircraftEmployment.inflightReportRequirementIndicatorCode"  /> 
<xsd :element  ref ='  Action AircraftEmployment.egressDirectionAngle "  /> 

<xsd:element  ref="ActionAircraftEmployment.approachOffsetCode"  /> 

<xsd:element  ref ="ActionResource. index"  /> 

<xsd:element  ref="Action.id"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 

<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

<xsd: element  name  =" ActionAircraft Employment. approachOffsetCode"> 

-  <xsd:simpleType> 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  ="ActionEffect.descriptionCode"> 
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-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="BURN"  /> 

<xsd:enumeration  value="CAPTUR"  /> 

<xsd:enumeration  value="CONS"  /> 

<xsd:enumeration  value="DEST"  /> 

<xsd:enumeration  value="FKIL"  /> 

<xsd:enumeration  value="FLIG"  /> 

<xsd:enumeration  value="IDNT"  /> 

<xsd:enumeration  value="ILLUMN"  /> 

<xsd:enumeration  value="KILL"  /> 

-  <!  —break  in  schema -  -  > 

<xsd:element  name  ="ActionEvent.subcategoryCode"> 

-  <xsd:simpleType> 

-  <xsd:  restriction  base="xsd:string"> 

-  <!  —break  in  schema,  following  actions  are  not  sequential  or  all-inclusive . -  -  > 

<xsd:enumeration  value  =  "ATTACK"  /> 

<xsd:enumeration  value  =  "DEFEAT"  /> 

<xsd:enumeration  value  =  "DEFEND"  /> 

<xsd:enumeration  value  =  "DEFLCT"  /> 

<xsd:enumeration  value  =  "DELAY"  /> 

<xsd:enumeration  value  =  "DEMO"  /> 

<xsd:enumeration  value  =  "DENY"  /> 

< xsd : enumeration  value  =  "DEPLOY"  / > 

<xsd:enumeration  value="SECURE"  /> 

<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

<!  —break  in  schema -  -  > 

<xsd:element  name  ="ActionObjectiveItem"> 

-  <xsd:complexType> 

-  <xsd :sequence> 
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<xsd:element  ref="ActionObjectiveItem.categoryCode"  /> 
<xsd:element  ref ="ActionObjective. index"  /> 

<xsd:element  ref="Action.id"  /> 

<xsd:element  ref="ObjectItem.id"  /> 

<xsd:element  ref="CandidateTargetList.id"  /> 

<xsd:element  ref ="CandidateTargetDetail. index"  /> 

<xsd:element  ref ="updateSequenceNumber"  minOccurs  ="0"  /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

<!  —break  in  schema . -  -  > 

<xsd:element  name  ="ActionResource"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref ="ActionResource. index"  /> 

<xsd:element  ref="ActionResource.qualifierCode"  /> 
<xsd:element  ref="ActionResource.criticalityIndicatorCode"  /> 
<xsd:element  ref="ActionResource.categoryCode"  /> 

<xsd:element  ref="Action.id"  /> 

<xsd:element  ref ="AuthorisingOrganisation.id "  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

<xsd:element  name  ="ActionResource.categoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="RI"  /> 

<xsd:enumeration  value="RT"  /> 

<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 
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</xsd:simpleType> 

</xsd:  element  > 

-  <!  —break  in  schema . -  -  > 

</xsd:element> 

<xsd:element  name  ="ActionTask.estimatedDuration"  type  ="xsd:decimal"  /> 

<xsd:element  name  ="ActionTask.id"  type="xsd:long"  /> 

<xsd:element  name  ="ActionTask.maximumDuration"  type  ="xsd:decimal"  /> 
<xsd:element  name  ="ActionTask.minimumDuration"  type="xsd:decimal"  /> 
<xsd:element  name  ="ActionTask.plannedEndDate"  type  ="xsd:int"  /> 
<xsd:element  name  ="ActionTask.plannedEndTime"  type  ="xsd:int"  /> 
<xsd:element  name  ="ActionTask.plannedStartDate"  type  ="xsd:int"  /> 
<xsd:element  name  ="ActionTask.plannedStartTime"  type="xsd:int"  /> 

-  <xsd:element  name  ="ActionTask.priorityCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="l"  /> 

<xsd:enumeration  value="2"  /> 

<xsd:enumeration  value="3"  /> 

<xsd:enumeration  value="4"  /> 

<xsd:enumeration  value="5"  /> 

<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

-  <xsd:element  name  ="ActionTask.startPrecisionCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="DAY"  /> 

<xsd:enumeration  value="HR"  /> 

<xsd:enumeration  value="MIN"  /> 

<xsd:enumeration  value="MON"  /> 

<xsd:enumeration  value="NKN"  /> 

<xsd:enumeration  value="SEC"  /> 
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<xsd:enumeration  value="WEK"  /> 

<xsd:enumeration  value="YEA"  /> 

<xsd:enumeration  value=""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

-  <!  —break  in  schema -  -  > 

<xsd:element  name  ="CandidateTargetList"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref="CandidateTargetList.id"  /> 

<xsd:element  ref ="CandidateTargetList. name  /> 

<xsd:element  ref="ReportingData.id"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 

<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element 

-  <!  —break  in  schema -  -  > 

<xsd:element  name  ="ConsumableMaterielType"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd: element  ref ="ConsumableMaterielType.perishabilityIndicatorCode  /> 
<xsd: element  ref ="ConsumableMaterielType.issuingWeightQuantity  '  /> 
<xsd:  element  ref="ConsumableMaterielType.  issuing  Width  Dimension"  /> 

<xsd:element 
<!  —break  in  schema -  -  > 

<xsd:element  name  ="ConsumableMaterielType.categoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="AMM"  /> 

<xsd:enumeration  value="CLO"  /> 

<xsd:enumeration  value="CON"  /> 
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<xsd:enumeration  value="FOO"  /> 
<xsd:enumeration  value="MED"  /> 


-  <!  —break  in  schema . -  -  > 

-  <xsd:element  name  ="Convoy"> 

-  <xsd:complexType> 

-  <xsd :sequence> 

<xsd:element  ref  =  Convoy. packetSizeQuantity  /> 
<xsd:element  ref=‘ Convoy. packetGapDimension '  /> 
<xsd:element  ref  =  Convoy. nightVehicleGapDimension "  /> 
<xsd:element  ref="Convoy.nightSpeedRate"  /> 

<xsd:element  ref="Convoy.haltDuration"  /> 

<xsd:element  ref  =  Convoy. dayVehicleGapDimension  '  /> 

<xsd:element  ref="Convoy.daySpeedRate"  /> 

<xsd:element  ref="Convoy.id"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 


-  <!  —break  in  schema . -  -  > 

</xsd:element> 

<xsd:element  name  ="EquipmentType.id"  type="xsd:long"  /> 

<xsd:element  name  ="EquipmentType.loadedWeightQuantity "  type  ="xsd:decimal"  /> 
<xsd:element  name  ="EquipmentType.maximumHeightDimension"  type  ="xsd:decimal"  /> 
<xsd:element  name  ="EquipmentType.maximumLengthDimension"  type="xsd:decimal"  /> 
<xsd:element  name  ="EquipmentType.maximumWidthDimension"  type="xsd:decimal"  /> 

-  <xsd:element 

-  <!  —break  in  schema . -  -  > 

-  <xsd:element  name  ="FacilityStatus.operationalStatusQualifierCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="DENY"  /> 
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<xsd:enumeration  value="DESTR"  /> 

<xsd:enumeration  value="HVYDAM"  /> 

<xsd:enumeration  value="LGTDAM"  /> 

<xsd:enumeration  value="LST"  /> 

<xsd:enumeration  value="LVR"  /> 

<xsd:enumeration  value="MODDAM"  /> 

<xsd:enumeration  value="NKN"  /> 

<xsd:enumeration  value="UNCNST"  /> 

<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

-  <!  —break  in  schema . -  -  > 

<xsd: element  name  ="GeographicFeatureStatus.surfaceConditionCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="DUST"  /> 

<xsd:enumeration  value="FLODNG"  /> 

<xsd:enumeration  value="GRASS"  /> 

<xsd:enumeration  value="ICE"  /> 

<xsd:enumeration  value="MARSH"  /> 

<xsd:enumeration  value="NOS"  /> 

<xsd:enumeration  value="SAND"  /> 

<xsd:enumeration  value="SCRUB"  /> 

<xsd:enumeration  value="SNOW"  /> 

<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  ="Light.categoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="CIVIL"  /> 
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<xsd:enumeration  value="DARK"  /> 

<xsd:enumeration  value="DAY"  /> 

<xsd:enumeration  value="MOON"  /> 

<xsd enumeration  value  ="NAUTIC"  /> 

<xsd:enumeration  value=""  /> 

</xsd:  restriction  > 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  ="Location"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref="Location.id"  /> 

<xsd:element  ref="Location.categoryCode"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  ="MaterielType"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref="MaterielType.stockNumberText"  /> 
<xsd:element  ref="MaterielType.categoryCode"  /> 

<xsd:element  ref="MaterielType.id"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  ="Minefield"> 

-  <xsd:complexType> 

-  <xsd :sequence> 
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<xsd:element  ref  = 'Minefield. purposeCode  /> 

<xsd:element  ref="Minefield.persistenceCode"  /> 

<xsd:element  ref="Minefield.patternCode"  /> 

<xsd:element  ref = "Minefield. mineSpacingDimension"  /> 

<xsd:element  ref="Minefield.id"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  ="ObjectItem"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref="ObjectItem.id"  /> 

<xsd:element  ref="ObjectItem.name"  /> 

<xsd:element  ref="ObjectItem.categoryCode"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

<xsd:element  name  ="ObjectItem.categoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="FA"  /> 

<xsd:enumeration  value="FE"  /> 

<xsd:enumeration  value="MA"  /> 

<xsd:enumeration  value="OR"  /> 

<xsd:enumeration  value="PE"  /> 

<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 
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-  <!  —break  in  schema . -  -  > 

<xsd: element  name  ="Orga nisationOrganisation Association. subcategoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="ADMIN"  /> 

<xsd:enumeration  value="ALTFOR"  /> 

<xsd:enumeration  value="ASGND"  /> 

<xsd:enumeration  value="ATPRCL"  /> 

<xsd:enumeration  value  ="ATTACH"  /> 

<xsd:enumeration  value="CAPT"  /> 

<xsd:enumeration  value="COMD"  /> 

<xsd:enumeration  value="DIRSUP"  /> 

<xsd:enumeration  value="FORCE"  /> 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  ="Person"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref="Person.religionCode"  /> 

<xsd:element  ref="Person.genderCode"  /> 

<xsd:element  ref="Person.bloodTypeCode"  /> 

<xsd:element  ref="Person.birthDate"  /> 

<xsd:element  ref="Person.alternateIdentificationText"  /> 

<xsd:element  ref="Person.id"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0" /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

<xsd:element  name  ="Person.alternateIdentificationText"  type  ="xsd:string"  /> 

<xsd:element  name  ="Person.birthDate"  type="xsd:int"  /> 

<xsd:element  name  ="Person.bloodTypeCode"> 

-  <xsd:simpleType> 
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-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="A+"  /> 
<xsd:enumeration  value="A-"  /> 
<xsd:enumeration  value="AB  +  "  /> 
<xsd:enumeration  value="AB-"  /> 
<xsd:enumeration  value="B  +  "  /> 
<xsd:enumeration  value="B-"  /> 
<xsd:enumeration  value="NKN"  /> 
<xsd:enumeration  value="0  +  "  /> 
<xsd:enumeration  value="0-"  /> 
<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

<xsd:element  name  ="Person.genderCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="F"  /> 
<xsd:enumeration  value="M"  /> 
<xsd:enumeration  value="NKN"  /> 
<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

<xsd:element  name  ="Person.id"  type="xsd:long"  /> 
<xsd:element  name  ="Person.religionCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="ATH"  /> 
<xsd:enumeration  value="BUD"  /> 
<xsd:enumeration  value="GRC"  /> 
<xsd:enumeration  value="HIN"  /> 
<xsd:enumeration  value="JUD"  /> 


<xsd:enumeration  value="MUSLIM"  /> 
<xsd:enumeration  value="NKN"  /> 
<xsd:enumeration  value="NON"  /> 
<xsd:enumeration  value="ORT"  /> 
<xsd:enumeration  value="PRO"  /> 
<xsd:enumeration  value="ROM"  /> 
<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  ="Precipitation.categoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="DRZLE"  /> 
<xsd:enumeration  value="FDRZLE"  /> 
<xsd:enumeration  value="FRAIN"  /> 
<xsd:enumeration  value="HAIL"  /> 

<xsd  enumeration  value  ="  ICECRY  "  /> 
<xsd:enumeration  value="ICEPLT"  /> 
<xsd:enumeration  value="NPR"  /> 
<xsd:enumeration  value="RAIN"  /> 
<xsd:enumeration  value  ="RAINSR"  /> 
<xsd:enumeration  value="SLEET"  /> 
<xsd:enumeration  value="SNOW"  /> 
<xsd:enumeration  value="SNWGRN"  /> 
<xsd:enumeration  value="SNWSHR"  /> 
<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  =" Reference. transmittalTypeCode"> 
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-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="COUMSG"  /> 
<xsd:enumeration  value="EMLMSG"  /> 
<xsd:enumeration  value="FAXMSG"  /> 
<xsd:enumeration  value="NKN"  /> 
<xsd:enumeration  value="NOS"  /> 
<xsd:enumeration  value="PHNMSG"  /> 
<xsd:enumeration  value="RADMSG"  /> 
<xsd:enumeration  value="SFXMSG"  /> 
<xsd:enumeration  value="TELEX"  /> 
<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  ="Route.mobilityCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="FOOT"  /> 
<xsd:enumeration  value="NKN"  /> 
<xsd:enumeration  value="TRACK"  /> 
<xsd:enumeration  value="WHEEL"  /> 
<xsd:enumeration  value="WHTR"  /> 
<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

-  <!  —break  in  schema . -  -  > 

<xsd:element  name  ="RuleOfEngagement"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref="RuleOfEngagement.id"  /> 


<xsd:element  ref="RuleOfEngagement.descriptionText"  /> 
<xsd:element  ref="RuleOfEngagement.name"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

-  <!  —break  in  schema -  -  > 

<xsd:element  name  ="SurveillanceCapability.categoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="COM"  /> 

<xsd:enumeration  value="ELC"  /> 

<xsd:enumeration  value="HUM"  /> 

<xsd:enumeration  value="IMG"  /> 

<xsd:enumeration  value="NKN"  /> 

<xsd:enumeration  value="NOS"  /> 

<xsd:enumeration  value="SIG"  /> 

<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

-  <!  —break  in  schema -  -  > 

<xsd:element  name  ="TargetMarking"> 

-  <xsd:complexType> 

-  <xsd :sequence> 

<xsd:element  ref="TargetMarking.startTime"  /> 

<xsd:element  ref="TargetMarking.startDate"  /> 

<xsd:element  ref="TargetMarking.methodCode"  /> 
<xsd:element  ref ="ActionObjective. index"  /> 

<xsd:element  ref="Action.id"  /> 

<xsd:element  ref="UsingOrganisation.id"  /> 

<xsd:element  ref="updateSequenceNumber"  minOccurs  ="0"  /> 
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<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

<!  —break  in  schema . -  -  > 

<xsd:element  name  ="UnitType"> 

-  <xsd:complexType> 

-  <xsd:sequence> 

<xsd:element  ref="UnitType.sizeCode"  /> 

<xsd:element  ref="UnitType.serviceCode"  /> 

<xsd:element  ref="UnitType.mobilityCode"  /> 

<xsd:element  ref="UnitType.categoryCode"  /> 

<xsd:element  ref="UnitType.id"  /> 

<xsd:element  ref="PrincipalEquipmentType.id"  /> 

<xsd:element  ref ="updateSequenceNumber"  minOccurs  ="0"  /> 
<xsd:element  ref="ownerId"  minOccurs  ="0"  /> 

</xsd:sequence> 

</xsd:complexType> 

<!  —break  in  schema . -  -  > 

<xsd:element  name  ="Visibility.categoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value-'DSTSND"  /> 

<xsd:enumeration  value="BLWSNW"  /> 

<xsd:enumeration  value="DSTDVL"  /> 

<xsd:enumeration  value  ="DSTSTR"  /> 

<xsd:enumeration  value="FOG"  /> 

<xsd:enumeration  value="FRZFOG"  /> 

<xsd:enumeration  value="HAZE"  /> 

<xsd:enumeration  value="SNDSTR"  /> 

<xsd:enumeration  value="SMOKE "  /> 

<xsd:enumeration  value="NKN"  /> 
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<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

-  <!  —break  in  schema . -  -  > 

-  <xsd:element  name  ="Wind.categoryCode"> 

-  <xsd:simpleType> 

-  <xsd: restriction  base="xsd:string"> 

<xsd:enumeration  value="CONST"  /> 

<xsd:enumeration  value="GUST"  /> 

<xsd:enumeration  value="NKN"  /> 

<xsd:enumeration  value="SQUAL"  /> 

<xsd:enumeration  value-'TRBLEX"  /> 

<xsd:enumeration  value="TRBLLI"  /> 

<xsd:enumeration  value="TRBLMO"  /> 

<xsd:enumeration  value="TRBLSE"  /> 

<xsd:enumeration  value="VRB"  /> 

<xsd:enumeration  value  =  ""  /> 

</xsd:  restriction  > 

</xsd:simpleType> 

</xsd:element  > 

<xsd:element  name  ="Wind.directionAngle "  type  ="xsd:decimal"  /> 

<xsd:element  name  ="Wind.id"  type  ="xsd:long"  /> 

<xsd:element  name  ="Wind.speedRate"  type  ="xsd:decimal"  /> 

-  <xsd:element  name  ="WindTable"> 

-  <xsd:complexType> 

-  <xsd :sequence> 

<xsd:element  ref="Wind"  maxOccurs  ="unbounded"  /> 
</xsd:sequence> 

</xsd:complexType> 

</xsd:element  > 

<xsd:element  name  ="ownerId"  type="xsd:long"  /> 

<xsd:element  name  ="updateSequenceNumber"  type="xsd:long"  /> 

</xsd:schema  > 
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APPENDIX  L.  GENERIC  HUB  COMPLIANT  OPERATION  ORDER 


A.  INTRODUCTION 

This  is  a  fraction  of  a  GH  compliant  order  that  follows  the  rules  of  the  GH  schema.  As  this  order  is  in  excess  of  142  pages,  it 
is  not  included  it  its  entirety.  Data  was  retrieved  from  each  section  of  the  order  in  order  to  portray  enough  information  to  obtain  a 
reasonable  appreciation  of  its  contents.  This  is  what  the  order  in  Appendix  J  must  transform  into  to  be  compliant  with  the  database. 
Franciso  Loaiza  of  the  Institute  for  Defense  Analysis  generated  this  order. 

B.  GH  OPERATION  ORDER 

-cr¬ 
edited  with  XML  Spy  v4.0  U  beta  3  build  Aug  24  2001  (http://www.xmlspy.com)  by  FRANCISCO  L  LOAIZA  (SED) 

--  > 

<GH4Complete  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

xsi:nol\lamespaceSchemaLocation="C:\Program  Files\Altova\XML  Spy  Suite\GH4Complete_3b.xsd"> 

-  cObjectltemTable  > 

-  <ObjectItem> 

<0bjectltem.id>555550001  </ObjectItem.id  > 
cObjectltem.name  >BLTl/4</0bjectItem.name  > 

<ObjectItem.categoryCode>OR</ObjectItem.categoryCode> 

<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
cownerld  >81 234567890  </ownerId  > 

</ObjectItem> 

-  <ObjectItem> 

cObjectltem.  id  >555550002  </ObjectItem.  id  > 
cObjectltem.name  >ALPHA</ObjectItem.name  > 
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<ObjectItem.categoryCode>OR</ObjectItem.categoryCode> 
<updateSequencelMumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550003</0bjectltem.id  > 

<ObjectItem.name  >lst  PLATOON</ObjectItem.name  > 
<ObjectItem.categoryCode>OR</ObjectItem.categoryCode> 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<ObjectItem.id  >555550004  </ObjectItem.  id  > 

<ObjectItem.name  >2nd  PLATOON</ObjectItem.name  > 
<ObjectItem.categoryCode>OR</ObjectItem.categoryCode> 
<updateSequencel\lumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550005  </ObjectItem.id  > 

<ObjectItem.name  >3rd  PLATOON</ObjectItem.name  > 
<ObjectItem.categoryCode>OR</ObjectItem.categoryCode> 
<updateSequencel\lumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<ObjectItem.  id  >555550006  </ObjectItem.  id  > 

<ObjectItem.name  >InsertStartPoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE</ObjectItem.categoryCode> 
<updateSequencel\lumber>7  7  7771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 


164 


<0bjectltem.id>555550007</0bjectltem.id  > 

<ObjectItem.name  >Beach  Landing  Site</ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550008</0bjectltem.id  > 

<ObjectItem.name  >InfilStartPoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550009  </ObjectItem.id  > 

<ObjectItem.name  >InfilEndPoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE</ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId  >81 234567890  </ownerId  > 

</ObjectItem> 

<ObjectItem> 

<ObjectItem.  id  >5555500 10  </ObjectItem.  id  > 

<ObjectItem.name  >InfilWaypoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE</ObjectItem.categoryCode> 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550011  </ObjectItem.id  > 

<ObjectItem.name  >InfilWaypoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 
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</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550012</0bjectltem.id  > 

<ObjectItem.name  >InfilWaypoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
<updateSequencel\lumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550013  </ObjectItem.id  > 

<ObjectItem.name  >ObjStartPoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<ObjectItem.  id  >5555500 14  </ObjectItem.  id  > 
<ObjectItem.name>ObjEndPoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE</ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550015</0bjectltem.id  > 

<ObjectItem.name  >ExfilStartPoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE</ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550016</0bjectltem.id  > 

<ObjectItem.name  >ExfilEndPoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
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<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550017  </ObjectItem.id  > 

<ObjectItem.name  >ExfilWaypoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
<updateSequencel\lumber>7  7  7771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550018</0bjectltem.id  > 

<ObjectItem.name  >ExfilWaypoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE</ObjectItem.categoryCode> 
<updateSequencel\lumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550019</0bjectltem.id> 

<ObjectItem.name  >ExtractionStartPoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE</ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId  >81 234567890  </ownerId  > 

</ObjectItem> 

<ObjectItem> 

<ObjectItem.  id  >555550020  </ObjectItem.  id  > 

<ObjectItem.name  >ExtractionEndPoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550021  </ObjectItem.id  > 
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<ObjectItem.name  >Pendleton  AF  </ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
<updateSequencelMumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550022</0bjectltem.id  > 

<ObjectItem.name  >AAAV </ObjectItem.name  > 
<ObjectItem.categoryCode>FE</ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550023</0bjectltem.id> 

<ObjectItem.name  >AAAV </ObjectItem.name  > 
<ObjectItem.categoryCode>FE</ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<ObjectItem.  id  >555550024  </ObjectItem.  id  > 

<ObjectItem.name  >AAAV </ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 

<ObjectItem> 

<0bjectltem.id>555550025  </ObjectItem.id  > 

<ObjectItem.name  >USCINCCENT </ObjectItem.name  > 
<ObjectItem.categoryCode>OR</ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItem> 
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-  <ObjectItem> 

<0bjectltem.id>555550026</0bjectltem.id> 

<ObjectItem.name  >InsertEndPoint</ObjectItem.name  > 
<ObjectItem.categoryCode>FE  </ObjectItem.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</0bjectItem> 

</ObjectItemTable  > 

<ObjectTypeTable  > 

-  <0bjectType> 

<0bjectType.id  >777770001</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  Battalion  Landing  Team  </0bjectType. name  > 
<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>OR</ObjectType.categoryCode> 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</0bjectType> 

-  <0bjectType> 

<0bjectType.id  >777770002</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  >Company  </ObjectType.name  > 

<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>OR</ObjectType.categoryCode> 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</0bjectType> 

-  <0bjectType> 

<0bjectType.id  >777770003</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  >Platoon</ObjectType.name  > 

<ObjectType.durnmyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 

<ObjectType.categoryCode>OR</ObjectType.categoryCode> 
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<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectType> 

<ObjectType> 

<ObjectType.id  >777770004</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  >Insertion  Point </ObjectType. name  > 
<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>FE</ObjectType.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectType> 

<ObjectType> 

<ObjectType.id  >777770005</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  >Infiltration  Point </ObjectType. name  > 
<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>FE  </ObjectType.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectType> 

<ObjectType> 

<ObjectType.id  >777770006</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  >Waypoint</ObjectType.name  > 

<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>FE</ObjectType.categoryCode> 
<updateSequencelMumber>777771 23456789  0</updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectType> 

<ObjectType> 

<ObjectType.id  >777770007</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 


170 


<ObjectType.name  >Objective  Point </ObjectType. name  > 
<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>FE  </ObjectType.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectType> 

<ObjectType> 

<ObjectType.id  >777770008</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  >Exfiltration  Point </ObjectType. name  > 
<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>FE  </ObjectType.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId  >81 234567890  </ownerId  > 

</ObjectType> 

<ObjectType> 

<ObjectType.id  >777770009</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  >Extraction  Point </ObjectType. name  > 
<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>FE</ObjectType.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectType> 

<ObjectType> 

<ObjectType.id  >777770010</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  >Airport  Field  </ObjectType. name  > 
<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>FA</ObjectType.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ObjectType> 
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-  <ObjectType> 

<ObjectType.id  >777770011</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  >Armored  Vehicle  </ObjectType. name  > 
<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode  >MA</ObjectType.categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</0bjectType> 

-  <0bjectType> 

<0bjectType.id  >777770012</ObjectType.id  > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name  >CINC  </ObjectType.name  > 

<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>OR</ObjectType.categoryCode> 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</0bjectType> 

</ObjectTypeTable  > 

<OrganisationTable  > 

-  <Organisation> 

Organisation. nicknameName  >BLTl/4</Organisation. nicknameName  > 
<Organisation.categoryCode  >UN</Organisation.categoryCode> 

Organisation,  id  >5  5555000 1</Organisation.  id  > 

<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</Organisation> 

-  Organisation> 

Organisation,  nickname  Name  >USCINCCENT  </Organisation.  nickname  Name  > 
Organisation.categoryCode>UN</Organisation.categoryCode> 

Organisation,  id  >5  55550025  </Organisation.  id  > 

<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<owner!d>81234567890</ownerId  > 
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</Organisation> 

</OrganisationTable  > 

<ReferenceTable  > 

-  <Reference> 

<Reference.id  >5250001</  Reference. id  > 

<  Reference.  transmittalTypeCode>TELEX</  Reference.transmittalTypeCode> 

<Reference.sourceText  >JTF  167</Reference.sourceText  > 

<Reference.securityClassificationCode>NU  </  Reference.  securityClassificationCode> 
<Reference.identificationText  >Exercise  Id:  EXER;  NickName:  XML01;  Messageld:  MSGID; 
MsgFormat:  ORDER;  SerialNumber:  129005;  OrderTy:  ORDTY;  PlanTy:  FRAGORD;  Authority: 
USCINCCENT;  OpOrderNr:  A101  </ Reference. identificationText  > 

<Reference.formatCode>USMTF  </ Reference. formatCode> 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Reference> 

-  <Reference> 

<Reference.id  >5250002</  Reference. id  > 

<  Reference.  transmittalTypeCode>TELEX</  Reference.  transmittalTypeCode> 

<Reference.sourceText  >JTF  167</Reference.sourceText  > 

<Reference.securityClassificationCode>NU  </  Reference.  securityClassificationCode> 

<Reference. identificationText  >Exercise  Id:  EXER;  NickName:  XML01;  Messageld:  MSGID; 
MsgFormat:  ORDER;  SerialNumber:  129005;  OrderTy:  ORDTY;  PlanTy:  FRAGORD;  Authority: 
USCINCCENT;  OpOrderNr:  A101  </Reference. identificationText > 

<Reference.formatCode>USMTF  </Reference.formatCode> 

<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</Reference> 

</ReferenceTable  > 

<ReportingDataTable  > 

-  <ReportingData> 

<  Reporting  Data,  id  >22220001  </  ReportingData.id  > 

<ReportingData.timingCategoryCode>RDABST</  ReportingData.timingCategoryCode> 

<  Reporting  Data.  reportingTime  >54000  </  ReportingData.reportingTime  > 


173 


<  Repo  rting  Data,  repo  rting  Date  >365 18  </  ReportingData.reportingDate> 
<ReportingData.credibilityCode>TRSTED</  ReportingData.credibilityCode> 
<ReportingData.countingIndicatorCode>NO</  Reporting  Data.countingIndicatorCode> 

<  Reporting  Data,  confirmationl  ndicatorCode>  NO  </  Reporting  Data.confirmationIndicatorCode> 
<ReportingData.categoryCode>REP</  ReportingData.categoryCode> 

<Reference.id  >5250001</  Reference. id  > 

<ReportingOrganisation.id  >55555000 1</  ReportingOrganisation.id> 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 

<ownerId  >81 234567890  </ownerId  > 

</ReportingData> 

<!  —  AdditonalReportingData  follows -  -  > 

-  <ObjectItemTypeTable  > 

-  <ObjectItemType> 

<ObjectItemType.  index  >33300001  </ObjectItemType.index> 

<0bjectltem.id>555550001  </ObjectItem.id  > 

<ObjectType.id  >777770001</ObjectType.id  > 

<  Reporting  Data,  id  >22220001  </  ReportingData.id  > 

<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ObjectItemType> 

<!  —  Additonal  Objectltem  TypeTable  data  follows -  -  > 

-  <FeatureTable  > 

-  <Feature  > 

<Feature.categoryCode>CF</Feature.categoryCode> 

<Feature.id>555550006</Feature.id> 

<updateSequenceNumber>77777 1234567890  </updateSequenceNumber> 

<ownerId  >81234567890  </ownerId  > 

</ Feature  > 

<!  —Additonal  FeatureTable  data  follows . --> 

-  <LocationTable  > 

-  <Location  > 

<Location.id  >88880001  </ Location. id  > 

<Location.categoryCode  >PT  </Location  .categoryCode  > 
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<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Location  > 

-  <!  — Additonal  LocationTable  data  follows -  -  > 

<FeatureLocationTable  > 

-  <FeatureLocation  > 

<FeatureLocation.index>111110001</Featu  relocation.  index> 
<FeatureLocation.accuracyQuantity>0  </FeatureLocation.accuracyQuantity> 

<Location.id  >88880001  </  Location,  id  > 

<Feature.id  >555550006</Feature.id  > 

<ReportingData.id  >22220002  </  ReportingData.id  > 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</FeatureLocation  > 

-  <!  —Additonal  FeatureLocationTable  data  follows -  -  > 

<PointTable  > 

-  <Point  > 

<Point.verticalPrecisionCode>10M</Point.verticalPrecisionCode> 

<Point.horizontalPrecisionCode>10M</Point.horizontalPrecisionCode> 

<Point.categoryCode>ABS</Point.categoryCode> 

<Point.id  >8888000  l</Point.  id  > 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Point  > 

-  <!  —Additonal  PointTable  data  follows -  -  > 

<AbsolutePointTable  > 

-  <AbsolutePoint  > 

<AbsolutePoint.longitudeCoordinate>-  131.43425</AbsolutePoint.longitudeCoordinate> 
<Absol  utePoint.latitudeCoordinate  >-44. 65465  </AbsolutePoint.latitudeCoordinate> 
<AbsolutePoint.elevationCategoryCode>LOC  </AbsolutePoint.elevationCategoryCode> 
<AbsolutePoint.id  >88880001</AbsolutePoint.id  > 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
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<ownerId>81234567890</ownerId  > 
</AbsolutePoint  > 

-  <!  — Additonal  AbsolutePointTable  data  follows . -  -  > 


<ActionTable  > 

-  <Action  > 

<Action.id  >9999900001</Action.id  > 

<Action.name  >Secure  Camp  Pendleton  </ Action. name  > 
<Action.categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId  >81 234567890  </ownerId  > 

</ Action  > 

-  <Action  > 

<Action.id  >9999900002</Action.id  > 

<Action.name  >Insert  Troops</Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId  >81 234567890  </ownerId  > 

</  Action  > 

-  <Action  > 

<Action.id  >9999900003</Action.id  > 

<Action.name  >Move  Alpha  Company  to  IP1</ Action. name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ Action  > 

-  <Action  > 

<Action.id  >9999900004</Action.id  > 

<Action.name  >Move  Alpha  Company  to  IP2</Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<owner!d  >81 234567890  </owner!d  > 
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</Action  > 

<Action  > 

<Action.id  >9999900005  </Action.  id  > 

<Action.name  >Infiltrate  with  Alpha  Company  </ Action. name  > 
<Action.categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >9999900006  </Action.  id  > 

<Action.name  >Move  Alpha  Company  to  WP1  </Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId  >81 234567890  </ownerId  > 

</Action  > 

<Action  > 

<Action.id  >9999900007  </Action.  id  > 

<Action.name  >Move  Alpha  Company  to  WP2</ Action. name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >9999900008  </Action.  id  > 

<Action.name  >Move  Alpha  Company  to  WP3  </Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequencel\lumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >9999900009  </Action.  id  > 

<Action.name  >Move  Alpha  Company  to  IP</Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
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<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >99999000 10  </Action.  id  > 

<Action.name  >Secure  Pendleton  AF  </ Action. name  > 

<Action.categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >99999000  ll</Action.  id  > 

<Action.name  >Secure  IP</Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ Action  > 

<Action  > 

<Action.id  >99999000 1 2  </Action.  id  > 

<Action.name  >Defend  IP</ Action. name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequencel\lumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId> 

</Action  > 

<Action  > 

<Action.id  >99999000 1 3  </Action.  id  > 

<Action.name  >Move  to  IP2</ Action. name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >99999000 14  </Action.  id  > 
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<Action.name  >Defend  IP2</ Action. name  > 

<Action.categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequencel\lumber>777771 234567890  </updateSequenceNumber> 
<ownerId  >81 234567890  </ownerId  > 

</Action  > 

<Action  > 

<Action.id  >99999000 1 5  </Action.  id  > 

<Action.name  >Move  to  IP3</ Action. name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >99999000 1 6  </Action.  id  > 

<Action.name  >Defend  IP3</Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>7  777  71 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >99999000 1 7  </Action.  id  > 

<Action.name  >Move  to  IP</Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId  >81 234567890  </ownerId  > 

</Action  > 

<Action  > 

<Action.id  >99999000 18  </Action.  id  > 

<Action.name  >Move  to  IP</Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 
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<Action  > 

<Action.id  >99999000 19  </Action.  id  > 

<Action.name  >Exfiltrate  Alpha  Company  </Action. name  > 
<Action.categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >9999900020</Action.id> 

<Action.name  >Move  Alpha  Company  to  WP3 </ Action. name > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequencelMumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >9999900021  </Action.  id  > 

<Action.name  >Move  Alpha  Company  to  WP2</Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action  > 

<Action.id  >99999000  22  </Action.  id  > 

<Action.name  >Move  Alpha  Company  to  WP1  </Action.name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Action  > 

<Action> 

<Action.id  >9999900023</Action.id> 

<Action.name  >Extract  Alpha  Company  </Action. name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequencelMumber>777771 234567890  </updateSequenceNumber> 
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<ownerId>81234567890</ownerId  > 

</ Action  > 

-  <Action  > 

<Action.id  >9999900024</Action.id  > 

<Action.name  >Move  to  BLS</Action.name > 

<Action.categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequencelMumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ Action  > 

-  <Action  > 

<Action.id  >9999900025</Action.id  > 

<Action.name  >Move  to  Extraction  Point </Action. name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId  >81 234567890  </ownerId  > 

</ Action  > 

-  <Action  > 

<Action.id  >9999900026</Action.id  > 

<Action.name  >Move  to  Exfiltration  End  Point </Action. name  > 

<Action.  categoryCode  >ACTTA  </Action  .categoryCode  > 
<updateSequenceNumber>77777 123  4567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</ Action  > 

</ActionTable  > 

<CandidateTargetListTable  > 

-  <CandidateTargetList  > 

<CandidateTargetList.id  >6566</CandidateTargetList.id> 
<CandidateTargetList.name  >The  Pendleton  AF  </CandidateTargetList.name  > 
<  Reporting  Data,  id  >22220001  </  ReportingData.id  > 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</CandidateTargetList  > 

</CandidateTa  rgetListTable  > 
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<CandidateTargetDetailTable  > 

-  <CandidateTargetDetail  > 

<CandidateTa  rgetDetail.index>1000001</CandidateTargetDetail.index> 
<CandidateTargetDetail.schemeCode>SITENR</CandidateTargetDetail.schemeCode> 
<CandidateTargetDetail.priorityQuantity>l  </CandidateTa  rgetDetail.priorityQuantity> 
<CandidateTargetDetail.labelText  /> 

<CandidateTargetDetail.focusTypeCode>NOS</CandidateTargetDetail.focusTypeCode> 
<CandidateTargetDetail.discriminatorCode>CTDITM  </CandidateTargetDetail.discriminatorCode> 
<CandidateTargetl_ist.id  >6566</CandidateTargetList.id> 

<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</CandidateTargetDetail  > 

-  <!  —  Additonal  CandidateTargetDetailTable  data  follows . -  -  > 

<ActionTaskTable  > 

-  <ActionTask> 

<ActionTask.plannedEndTime  >25200</ActionTask.plannedEndTime  > 

<ActionTask.minimumDu  ration  >0</ActionTask.  minimum  Du  ration  > 
<ActionTask.estimatedDuration  >0  </ActionTask.estimatedDuration  > 
<ActionTask.maximumDuration>0</ActionTask.maximumDu  ration  > 
<ActionTask.plannedStartDate>36518</ActionTask.plannedStartDate> 
<ActionTask.plannedStartTime  >54000</ActionTask.plannedStartTime  > 
<ActionTask.startPrecisionCode  >H  R</ActionTask.startPrecisionCode  > 

<ActionTask.categoryCode  >ORD  </ActionTask.categoryCode  > 

<ActionTask.  planned  End  Date  >365 19  </ActionTask.  planned  End  Date  > 
<ActionTask.endPrecisionCode>HR</ActionTask.endPrecisionCode  > 
<ActionTask.endQualifierCode  >NLT</ActionTask.endQualifierCode> 

<ActionTask.  priorityCode  >  1  </ActionTask.  priorityCode  > 

<ActionTask.verbPhraseCode>SECURE  </ActionTask.verbPhraseCode> 
<ActionTask.startQualifierCode>NLT  </ActionTask.startQualifierCode> 

<ActionTask.id  >9999900001</ActionTask.id  > 

<CandidateTargetl_ist.id  >6566  </  CandidateTargetList.id> 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<owner!d>81234567890</ownerId  > 
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</ActionTask> 

<ActionTask> 

<ActionTask.plannedEndTime  >64800</ActionTask.plannedEndTime  > 
<ActionTask.minimumDu  ration  >0  </ActionTask.  minimum  Du  ration  > 
<ActionTask.estimatedDuration  >0  </ActionTask.estimatedDuration  > 
<ActionTask.maximumDuration>0</ActionTask.maximumDu  ration  > 
<ActionTask.plannedStartDate>36518</ActionTask.plannedStartDate> 
<ActionTask.plannedStartTime  >54000</ActionTask.plannedStartTime  > 
<ActionTask.startPrecisionCode  >H  R</ActionTask.startPrecisionCode  > 
<ActionTask.categoryCode  >ORD  </ActionTask.categoryCode  > 

<ActionTask.  planned  End  Date  >365 18  </ActionTask.  planned  End  Date  > 
<ActionTask.endPrecisionCode>HR</ActionTask.endPrecisionCode  > 
<ActionTask.endQualifierCode>NLT</ActionTask.endQualifierCode> 
<ActionTask.priorityCode>l</ActionTask.priorityCode> 
<ActionTask.verbPhraseCode>INSERT</ActionTask.verbPhraseCode> 
<ActionTask.startQualifierCode  >NLT  </ActionTask.startQualifierCode> 
<ActionTask.id  >9999900002</ActionTask.id  > 

<CandidateTargetList.id  >6566  </  CandidateTargetList.id  > 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ActionTask> 

<ActionTask> 

<ActionTask.plannedEndTime  >64800</ActionTask.plannedEndTime  > 
<ActionTask.minimumDu  ration  >0  </ActionTask.  minimum  Du  ration  > 
<ActionTask.estimatedDuration  >0  </ActionTask.estimatedDuration  > 
<ActionTask.maximumDuration>0</ActionTask.maximumDu  ration  > 
<ActionTask.plannedStartDate>36518</ActionTask.plannedStartDate> 
<ActionTask.plannedStartTime  >54000</ActionTask.plannedStartTime  > 
<ActionTask.  startPrecisionCode  >H  R</ActionTask.startPrecisionCode  > 
<ActionTask.categoryCode  >ORD  </ActionTask.categoryCode  > 

<ActionTask.  planned  End  Date  >365 18  </ActionTask.  planned  End  Date  > 
<ActionTask.endPrecisionCode>HR</ActionTask.endPrecisionCode  > 
<ActionTask.endQualifierCode>NLT</ActionTask.endQualifierCode> 
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<ActionTask.priorityCode>l</ActionTask.priorityCode> 

<ActionTask.verbPhraseCode>MOVE  </ActionTask.verbPhraseCode> 
<ActionTask.startQualifierCode>NLT  </ActionTask.startQualifierCode> 

<ActionTask.  id  >9999900003  </ActionTask.  id  > 

<CandidateTargetl_ist.id  >6566  </  CandidateTargetList.id> 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ActionTask> 

-  <!  — Additonal  ActionTaskTable  data  follows . -  -  > 

<ActionFu notional AssociationTable  > 

-  <ActionFunctionalAssociation  > 

<Actio  n  Functional  Association.  index>331 23450000  l</Action  Functional  Association.  index> 
<ActionFunctiona  I  Association.categoryCode>HSA</Action  Functional  Association.  categoryCode> 
<ObjectAction.id>9999900001  </ObjectAction.id  > 

<SubjectAction.id  >9999900002</SubjectAction.id  > 

<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 

<ownerId  >81 234567890  </ownerId  > 

</ActionFunctionalAssociation> 

-  <!  —Additonal  ActionFunctionalAssociationTable  data  follows . -  -  > 

<ActionResourceTable  > 

-  <ActionResource> 

<ActionResource.index>33 1234560001  </ActionResource.index> 
<ActionResource.qualifierCode  >AUTH  </ActionResource.qualifierCode  > 
<ActionResource.criticalityIndicatorCode>YES</ActionResource.criticalityIndicatorCode> 

<A  ction  Resou  rce.  categoryCode  >RI</Action  Resource.  categoryCode> 

<Action.id  >9999900001</Action.id  > 

<AuthorisingOrganisation.id>555550025</AuthorisingOrganisation.id> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ActionResource 

-  <!  —Additonal  ActionResourceTable  data  follows . -  -  > 

<ActionResourceItemTable  > 
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-  <ActionResourceItem> 

<ActionResource.index>33 1234560001  </ActionResource.index> 

<Action.id  >9999900001</Action.id  > 

<0bjectltem.id>555550001  </0bjectItem.id  > 

<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ActionResourceItem> 

-  <!  —  Additonal  ActionResourceltemTable  data  follows -  -  > 

<ActionObjectiveTable  > 

-  <ActionObjective> 

<ActionObjective.  index  >441 234567001  </ActionObjective.index> 
<ActionObjective.priorityCode>l</ActionObjective.priorityCode> 
<ActionObjective.qualifierCode>AUTH  </ActionObjective.qualifierCode> 
<ActionObjective.categoryCode>OI</ActionObjective.categoryCode> 
<Action.id  >9999900001</Action.id  > 

<Authoris  i  ngOrga  n  isation.  id  >555550025  </AuthorisingOrganisation.id> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ActionObjective> 

-  <!  —Additonal  ActionObjectiveTable  data  follows . -  -  > 

<ContextTable  > 

-  <Context  > 

<Context.id  >92220001  </Context.id  > 

<Context.name  >SITUATION</Context.name  > 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId  >81 234567890  </ownerId  > 

</Context  > 

-  <Context  > 

<Context.id  >92220002  </Context.id  > 

<Context.name  >MISSION</Context.name  > 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<owner!d  >81 234567890  </owner!d  > 
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</Context  > 

-  <Context  > 

<Context.id  >92220003  </Context.id  > 

<Context.name  >EXECUTION</Context.name  > 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Context  > 

-  <Context  > 

<Context.id  >92220004  </Context.id  > 

<Context.name  >ADMIN  AND  LOGISTICS</Context.name  > 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</Context  > 

-  <Context  > 

<Context.id  >92220005  </Context.id  > 

<Context.name  >COMMAND  AND  CONTROL</ Context. name  > 
<updateSequencel\lumber>777771 234567890  </updateSequenceNumber> 
<ownerId>81234567890</ownerId  > 

</Context  > 

</ContextTable  > 

<ActionContextTable  > 

-  <ActionContext  > 

<ActionContext.index>1001  </ActionContext.index> 
<ActionContext.categoryCode>DES</ActionContext.categoryCode> 
<Context.id  >92220001  </Context.id  > 

<Action.id  >9999900001</Action.id  > 

<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ActionContext  > 

-  <!  —  Additonal  ActionContextTable  data  follows . -  -  > 

<ContextAssessmentTable  > 

-  <ContextAssessment  > 

<ContextAssessment.  index  >1001  </ContextAssessment.index> 
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<ContextAssessment.effectiveTime  >54000  </ContextAssessment.effectiveTime  > 
<ContextAssessment.effectiveDate>36518</ContextAssessment.effectiveDate> 

<ContextAssessment.text  >A.  GENERAL.  REFER  TO  BASIC  ORDER;  B.  ENEMY  FORCES.  REFER  TO 
BASIC  ORDER;  C.  FRIENDLY  FORCES.  REFER  TO  BASIC  ORDER;  D.  ATTACHMENTS  AND 
DETACHMENTS.  ANNEX  A  (TASK  ORGANIZATION)  </ContextAssessment. text  > 

<Context.id  >92220001  </Context.id  > 

<ContextAssessi  ^Organisation,  id  >555550001  </ContextAssessingOrganisation.id> 
<updateSequenceNumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ContextAssessment  > 

<ContextAssessment  > 

<ContextAssessment.  index  >1001  </ContextAssessment.index> 

<ContextAssessment.effectiveTime  >54000  </ContextAssessment.effectiveTime  > 
<ContextAssessment.effectiveDate>36518</ContextAssessment.effectiveDate> 

<ContextAssessment.text  >AT  H-HOUR,  BLT  1/4  CONDUCTS  AN  AAAV  RAID  ACROSS  RED  BEACH 
AND  PROCEEDS  INLAND  TO  SEIZE  ATF  OBJECTIVE  A.  ONCE  SEIZED,  MAINTAIN  SECURITY  OF 
OBJECTIVE  UNTIL  RELIEVED  BY  TF  APACHE.  </ContextAssessment. text  > 

<Context.id  >92220002  </Context.id  > 

<ContextAssessingOrganisation.id  >555550001  </ContextAssessingOrganisation.id> 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 
<ownerId>81234567890</ownerId  > 

</ContextAssessment  > 

<ContextAssessment  > 

<ContextAssessment.  index  >1001  </ContextAssessment.index> 

<ContextAssessment.effectiveTime  >54000  </ContextAssessment.effectiveTime  > 
<ContextAssessment.effectiveDate>36518</ContextAssessment.effectiveDate> 

<ContextAssessment.text  >3.  CONCEPT  OF  OPERATIONS.  AT  H-HOUR,  BLT  1/4  CONDUCTS  AN 
AMPHIBIOUS  RAID  TO  SEIZE  ATF  OBJECTIVE  A.  THREE  REINFORCED  PLATOONS  FROM 
COMPANY  A  WILL  CONDUCT  AN  AAAV  ASSAULT  ACROSS  RED  BEACH  AND  PROCEED  INLAND 
VIA  PREDETERMINED  ROUTE  TO  SEIZE  ATF  OBJECTIVE  A.  COMPANY  A  WILL  SECURE  THE 
OBJECTIVE  AND  REMAIN  UNTIL  RELIEVED  BY  TF  APACHE.  COMPANY  B  IS  THE  RESERVE. 
COMPANY  A  IS  THE  MAIN  EFFORT  AND  WILL  HAVE  PRIORITY  OF  FIRES  FOR  THE  DURATION 
OF  THE  OPERATION.  </ContextAssessment.text  > 
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<Context.id  >92220003  </Context.id  > 

<ContextAssessingOrganisation.id  >555550001  </ContextAssessingOrganisation.id> 
<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 

<ownerId  >81 234567890  </ownerId  > 

</ContextAssessment  > 

-  <!  — Additonal  ContextAssessmentTable  data  follows -  -  > 

-  <OrganisationActionTaskAssociationTable  > 

-  <OrganisationActionTaskAssociation  > 

<OrganisationActionTaskAssociation.index>  113301  </OrganisationActionTaskAssociation.index> 
<OrganisationActionTaskAssociation.intentText >1.  BATTALION  COMMANDERS  INTENT.  CURRENTLY 
THERE  IS  MINIMAL  THREAT  IN  OUR  ZONE.  HOWEVER,  MY  CONCERN  LIES  IN  THE  FACT  THAT 
CIVILIAN  REACTION  IS  UNCERTAIN  AND  THERE  ARE  GREAT  NUMBERS  OF  THEM  NEARBY.  AS 
WE  ARE  DEALING  WITH  A  CIVILIAN  GROUP,  I  SEE  THEIR  VULNERABILITY  AS 
RESPONSIVENESS  AND  LACK  OF  TRAINING.  I  INTEND  TO  EXPLOIT  THIS  BY  LANDING  EARLY 
IN  THE  MORNING  AND  MOVING  TO  THE  OBJECTIVE  QUICKLY  BEFORE  THE  GENERAL 
POPULACE  IS  AWAKE.  2.  ENDSTATE.  I  SEE  OUR  ENDSTATE  AS  ATF  OBJECTIVE  A  SECURED 
AND  IN  CONTROL  OF  CTF  175.  </OrganisationActionTaskAssociation.intentText  > 

<OrganisationActionTaskAssociation.effectiveTime  >54000</OrganisationActionTaskAssociation.effecti 
veTime  > 

<Orga  nisation  ActionTaskAssociation.  effective  Date  >365 18  </  Organisation  ActionTaskAssociation.effecti 
veDate> 

<Orga  n  isation  ActionTaskAssociation.  categoryCode>PROVDR</Orga  nisation  ActionTaskAssociation.  cat 
egoryCode> 

<ActionTask.id  >9999900001</ActionTask.id  > 

Organisation,  id  >5  5555000  l</Orga  nisation.  id  > 

<updateSequenceNumber>777771 234567890  </updateSequenceNumber> 

<ownerId  >81 234567890  </ownerId  > 

</Orga  nisation  ActionTaskAssociation  > 

</OrganisationActionTaskAssociationTable  > 

</GH4Complete> 
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APPENDIX  M.  XML  TO  XML  STYLESHEET 


A.  INTRODUCTION 

In  order  for  the  operation  order  in  Appendix  J  to  become  the  operation  order  in  Appendix  L,  and  consequently  compliant  with 
the  Generic  Hub  (GH),  an  XSL  stylesheet  is  applied  to  change  its  format.  Specifically,  XSLT  is  used  to  transform  one  XML 
document  into  another.  Once  “linked”,  operation  orders  can  be  produced  with  the  improved  XML-MTF  schema  (Appendix  I), 
transformed  into  orders  compliant  with  the  GH  schema  (Appendix  K)  and  read  into  the  database.  As  soon  as  autogeneration  of  the  3D 
scene  is  functional,  the  GH  database  can  feed  and  update  the  information  in  the  scene;  in  other  words  the  data  flow  and  transformation 
works  both  ways.  This  stylesheet  is  created  by  Doug  Horner  and  is  still  a  work  in  progress. 

B.  STYLESHEET 

<?xml  version  =  "1.0"  encoding  =  "UTF-8"?> 

<xsl : stylesheet  version  ="1.0"  xm Ins :xsl=" http://www.w3.org/1999/XSL/Transform"  > 

<xsl:output  method="xml"  indent  ="no"/> 

<xsl:template  match="/"> 

<xsl :  pa  ram  name  ="InitialFeatureNumber"  select="111110000"x/xsl :  param> 

<ObjectItemTable> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit  "> 
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<xsl :call-template  name  ="AssignOR"/> 

</xsl:for-each> 

<xsl  :for-each 

select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit/BattalionLandingTeam"  > 

<xsl :call-template  name  ="AssignOR"/> 

</xsl:for-each> 

<xsl  :for-each 

select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryl)nit/Batta[ionLandingTea  m/Company  "> 

<xsl :call-template  name  ="AssignOR"/> 

</xsl:for-each> 

<xsl  :for-each 

select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit/Batta  lion  La  ndingTea  m/Com  pa  ny/Platoon" 

> 

<xsl :call-template  name  ="AssignOR"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Mo vement/Insertion"> 

<xsl :  cal  I- tern  plate  name  ="AssignFE"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :  cal  I- tern  plate  name  ="AssignFE"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl:call-template  name  ="AssignFE"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl:call-template  name  ="AssignFE"/> 

</xsl:for-each> 
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<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Extraction"> 
<xsl :  cal  I- template  name  ="AssignFE"/> 

</xsl:for-each> 

</ObjectItemTable  > 

<ObjectTypeTable  > 


<xsl : if  test  ="/Order/Genera ITextl nformatio n/Tasks/Orga nization/Ma rineExped itionaryU nit  "> 

<xsl:call-template  name  ="AssignObjectTypeNumber"/> 

</  xsl :  if  > 

<xsl  :for-each 

select="/Order/Genera  ITextl  nformation/Tasks/Orga  nization/Ma  rineExped  itionaryUnit/Batta  lion  La  ndingTeam"  > 

<xsl icall-template  name  ="AssignObjectTypeNumber"/> 

</xsl:for-each> 

<xsl  :for-each 

select="/Order/Genera  ITextl  nformation/Tasks/Orga  nization/Ma  rineExped  itionaryUnit/Batta  lion  La  ndingTea  m/Company  "> 
<xsl:call-template  name  ="AssignObjectTypeNumber"/> 

</xsl:for-each> 

<xsl  :for-each 

select="/Order/Genera  ITextl  nformation/Tasks/Orga  nization/Ma  rineExped  itionaryUnit/Batta  lion  La  ndingTea  m/Com  pa  ny/Platoon" 

> 

<xsl:call-template  name  ="AssignObjectTypeNumber"/> 

</xsl:for-each> 

<xsl: for- each  select  ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/I nsertion"> 
<xsl:call-template  name  ="AssignObjectTypeNumber"/> 

</xsl:for-each> 

</ObjectTypeTable  > 

<OrganisationTable  > 
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<xsl : for- each  select ="/Order/OrderReference/OrderOriginatorAndOrl\lumber/MilitaryCornrnand Authority" > 
<xsl :  cal  I- template  name  ="Organisation"/> 

</xsl:for-each> 


<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit  "> 

<xsl :call-template  name  ="Organisation"/> 

</xsl:for-each> 

<xsl  :for-each 

select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit/BattalionLandingTeam"  > 
<xsl:call-template  name  ="Organisation"/> 

</xsl:for-each> 

<xsl  :for-each 

select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit/BattalionLandingTea  m/Company  "> 

<xsl :  cal  I- tern  plate  name  ="Organisation"/> 

</xsl:for-each> 

<xsl  :for-each 

select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit/Batta  lion  Land  ingTeam/Com  pa  ny/Platoon" 

> 

<xsl:call-template  name  ="Organisation"/> 

</xsl:for-each> 

</OrganisationTable  > 

<ReferenceTable  > 

<xsl :call-template  name  =" References"/> 

</ReferenceTable  > 

<ReportingDataTable  > 

<ReportingData> 

<ReportingData.id  >22220001  </  ReportingData.id  > 
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<ReportingData.timingCategoryCode>RDABST  </ReportingData.timingCategoryCode> 
<ReportingData.reportingTime  >54000</ReportingData.reportingTime  > 

<ReportingData.reportingDate>36518</  ReportingData.reportingDate> 

<Re  porting  Data.  credibilityCode>TRSTED</  ReportingData.credibilityCode> 
<ReportingData.countingIndicatorCode>NO</  ReportingData.countingIndicatorCode> 
<ReportingData.confirmationIndicatorCode>NO</ReportingData.confirmationIndicatorCode> 
<ReportingData.categoryCode>REP</ReportingData.categoryCode> 

<Reference.id  xxsl:  value- of 

select ="/Order/MessageIdentification/MessageSeriaH\lumber/@referenceIdNumber"/></  Reference,  id  > 
<ReportingOrganisation.id>  <xsl:  value- of 

select ="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit/@objectItemIdNumber"/x/ReportingOrg 
anisation.id  > 

<u  pdateSeq  uence  Number>777771234567890</updateSequencel\lumber> 

<ownerId  >81234567890</ownerld  > 

</  ReportingData> 

</ReportingDataTable  > 

<ObjectItemTypeTable  > 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit  "> 

<xsl :call-template  name  ="AssignObjectItemTypeIndex"/> 

</xsl:for-each> 

<xsl  :for-each 

select="/Order/GeneralTextInformation/Tasks/Organization/MarineExped  it  ionary  Unit/Battalion  La  ndingTeam"  > 

<xsl  icall-template  name  ="AssignObjectItemTypeIndex"/> 

</xsl:for-each> 

<xsl:for-each 

select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit/BattalionLandingTea  m/Company  "> 

<xsl icall-template  name  =" Ass ignObjectltemTy pel ndex"/> 

</xsl:for-each> 
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<xsl  :for-each 

select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionaryUnit/Batta  lion  La  ndingTea  m/Com  pa  ny/Platoon" 

> 

<xsl :call-template  name  ="AssignObjectItemTypeIndex"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInforrnation/Tasks/ExecutionTimelineAndMovement/Insertion"> 

<xsl :  ca  1 1-  template  name  ="AssignObjectItemTypeIndex"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :  call-template  name  ="AssignObjectItemTypeIndex"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl :call-template  name  ="AssignObjectItemTypeIndex"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl:call-template  name  ="AssignObjectItemTypeIndex"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Extraction "> 

<xsl :call-template  name  ="AssignObjectItemTypeIndex"/> 

</xsl:for-each> 

</ObjectItemTypeTable  > 

<FeatureTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/I nsertion"> 

<xsl :  ca  1 1-  template  name  ="FeatureTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 
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<xsl :  cal  I- template  name  ="FeatureTableIdNumber"/> 

</xsl:for-each> 

<xsl:for-each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl:call-template  name  ="FeatureTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Mo vement/Exfil"> 

<xsl :  cal  I- tern  plate  name  ="FeatureTableIdl\lumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Extraction "> 

<xsl :  cal  I- tern  plate  name  ="FeatureTableIdNumber"/> 

</xsl:for-each> 

</FeatureTable  > 

<LocationTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Insertion"> 
<xsl:call-template  name  ="LocationTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :  cal  I- tern  plate  name  ="LocationTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl:call-template  name  ="LocationTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl :  cal  I- tern  plate  name  ="LocationTableIdNumber"/> 

</xsl:for-each> 


195 


<xsl : for- each  select ="/Order/Genera  ITextInformation/Tasks/ExecutionTimelineAndMovement/Extraction"> 

<xsl :  cal  I- template  name  ="LocationTableIdNumber"/> 

</xsl:for-each> 

</LocationTable  > 

<FeatureLocationTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Insertion "> 
<xsl:call-template  name  ="FeatureLocationTableNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :call-template  name  ="FeatureLocationTableNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl :call-template  name  ="FeatureLocationTableNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl:call-template  name  ="FeatureLocationTablel\lumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Extraction"> 

<xsl :call-template  name  ="FeatureLocationTablel\lumber"/> 

</xsl:for-each> 

</FeatureLocationTable  > 

<PointTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Insertion"> 
<xsl:call-template  name  ="PointTableIdNumber"/> 

</xsl:for-each> 
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<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTirnelineAndMovement/Infiltration"> 

<xsl:call-template  name  ="PointTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select =70rder/GeneralTextInformation/Tasks/ExecutionTimelineAnd Move ment/ActionsAtTheObjective"> 
<xsl:call-template  name  ="PointTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl :  cal  I- tern  plate  name  ="PointTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Extraction "> 
<xsl:call-template  name  ="PointTableIdNumber"/> 

</xsl:for-each> 

</PointTable  > 

<AbsolutePointTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/I nsertion"> 
<xsl:call-template  name  ="AbsolutePointTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :  cal  I- tern  plate  name  ="AbsolutePointTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl:call-template  name  ="AbsolutePointTableIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl :  cal  I- tern  plate  name  ="AbsolutePointTableIdNumber"/> 
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</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTirnelineAnd Movement/Extraction "> 

<xsl :  cal  I- template  name  ="AbsolutePointTableIdNumber"/> 

</xsl:for-each> 

</AbsolutePointTable  > 

<ActionTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Insertion"> 
<xsl:call-template  name  ="ActionIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :  cal  I- tern  plate  name  ="ActionIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Actio nsAtTheObjective"> 
<xsl:call-template  name  ="ActionIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl:call-template  name  ="ActionIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Extraction "> 

<xsl :  cal  I- tern  plate  name  ="  Action  Id  N  urn  ber"/> 

</xsl:for-each> 

</ActionTable  > 

<CandidateTargetListTable  > 

<CandidateTargetList  > 

<CandidateTargetList.id  >6566</CandidateTargetList.id  > 
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<CandidateTargetList.name  >The  Pendleton  AF</CandidateTargetList.name  > 

<ReportingData.id  >22220001  </  Reporting  Data,  id  > 

<updateSequencel\lumber>77777 1234567890  </updateSequencel\lumber> 

<ownerId  >81234567890</ownerld  > 

</CandidateTargetList  > 

</CandidateTargetListTable  > 

<CandidateTargetDetailTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Insertion"> 

<xsl :  cal  I- template  name  ="CandidateTargetIndexNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :  cal  I- tern  plate  name  ="CandidateTargetIndexNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl :  cal  I- tern  plate  name  ="CandidateTargetIndexl\lumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl :  cal  I- tern  plate  name  ="CandidateTargetIndexl\lumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Extraction"> 

<xsl :  cal  I- tern  plate  name  ="CandidateTargetIndexNumber"/> 

</xsl:for-each> 


</CandidateTargetDetailTable  > 

<CandidateTargetDetailItemTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Insertion"> 
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<xsl :  cal  I- template  name  ="TargetDetailItemNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 
<xsl:call-template  name  ="TargetDetailItemNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl :  cal  I- tern  plate  name  ="TargetDetailItemNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl :  cal  I- tern  plate  name  ="TargetDetailItemNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/Genera IT extInformation/Tasks/ExecutionTimelineAndMovement/Extraction"> 

<xsl :  cal  I- tern  plate  name  ="TargetDetailItemNumber"/> 

</xsl:for-each> 

</CandidateTargetDetailItemTable  > 

<ActionTaskTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/I nsertion"> 

<xsl :call-template  name  ="ActionTaskReferenceTable"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :call-template  name  ="ActionTaskReferenceTable"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl :call-template  name  ="ActionTaskReferenceTable"/> 

</xsl:for-each> 
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<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl :call-template  name  ="ActionTaskReferenceTable"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Extraction "> 
<xsl :call-template  name  ="ActionTaskReferenceTable"/> 

</xsl:for-each> 


</ActionTaskTable  > 

<ActionFunctionalAssociationTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Insertion"> 

<xsl :  cal  I- tern  plate  name  ="  Action  Fu  nctiona  I  Association  I  ndexl\lumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :call-template  name  ="ActionFunctionalAssociationIndexNumber"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl :call-template  name  ="ActionFunctionalAssociationIndexNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Mo vement/Exfil"> 

<xsl :call-template  name  ="ActionFunctionalAssociationIndexNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Extraction "> 

<xsl:  cal  I- tern  plate  name  ="  Action  Functional  Association!  ndexNum  be  r"/> 

</xsl:for-each> 

</ActionFunctionalAssociationTable  > 
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<ActionResourceItemTable  > 


<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Insertion"> 

<xsl :call-template  name  ="ActionResourceItemTableIndex"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :call-template  name  ="ActionResourceItemTableIndex"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Actio nsAtTheObjective"> 
<xsl :call-template  name  ="ActionResourceItemTableIndex"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl :call-template  name  ="Action ResourceItemTableIndex"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Extraction "> 
<xsl:call-template  name  ="ActionResourceItemTableIndex"/> 

</xsl:for-each> 

</ActionResourceItemTable  > 

<ActionResourceItemTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Insertion"> 

<xsl :call-template  name  ="LinkingActionId20bjectItemIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/I nfiltration"> 

<xsl :call-template  name  ="LinkingActionId20bjectItemIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
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<xsl:  cal  I-  template  name  ="LinkingActionId20bjectItemIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl :call-template  name  ="LinkingActionId20bjectItemIdNumber"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Extraction "> 

<xsl :call-template  name  ="LinkingActionId20bjectItemIdNumber"/> 

</xsl:for-each> 

</ActionResourceItemTable  > 

<ActionObjectiveTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Insertion"> 

<xsl :call-template  name  ="ActionObjectiveTable"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :call-template  name  ="ActionObjectiveTable"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl :call-template  name  ="ActionObjectiveTable"/> 

</xsl:for-each> 

<xsl: for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl :call-template  name  ="ActionObjectiveTable"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Extraction"> 

<xsl :call-template  name  ="ActionObjectiveTable"/> 

</xsl:for-each> 
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</ActionObjectiveTable  > 

<ActionObjectiveItemTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTirnelineAndMovement/Insertion"> 

<xsl :call-template  name  ="ActionObjectiveItemCrossReferenceTable"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Infiltration"> 

<xsl :call-template  name  ="ActionObjectiveItemCrossReferenceTable"/> 

</xsl:for-each> 

<xsl: for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl :call-template  name  ="ActionObjectiveItemCrossReferenceTable"/> 

</xsl:for-each> 

<xsl : for- each  select="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl :call-template  name  ="ActionObjectiveItemCrossReferenceTable"/> 

</xsl:for-each> 

<xsl : for- each  select ="/Order/GeneralTextInformation/Tasks/ExecutionTimelineAnd Movement/Extraction "> 

<xsl:  cal  I- tern  plate  name  ="ActionObjectiveItemCrossReferenceTable"/> 

</xsl:for-each> 

</ActionObjectiveItemTable  > 

<ContextTable  > 

<xsl : for- each  select ="/Order/GeneralTextInformation/GentextTextIndicator"> 

<xsl :call-template  name  ="ContextTableNumbers "/> 

</xsl:for-each> 

</ContextTable  > 

<ActionContextTable  > 
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<xsl : for- each  select ="/Order/GeneralTextInformation/GentextTextIndicator"> 

<xsl :call-template  name  ="ActionContextReference"/> 

</xsl:for-each> 

</ActionContextTable  > 

<ContextAssessmentTable  > 

<xsl : if  test="/Order/GeneralTextInformation[@name  =  'Situation']  "> 

<ContextAssessment  > 

<ContextAssessment.index>1001</ContextAssessment.index> 

<ContextAssessment.effectiveTime  ></ContextAssessment.effectiveTime  > 
<ContextAssessment.effectiveDatex/ContextAssessment.effectiveDate> 

<ContextAssessment.text  ><xsl:value-of  select="/Order/GeneralTextInformation[(g)name 

Situation']/FreeText  "/> 

</ContextAssessment.text  > 

<Context.id  > 

<xsl:  value- of  select="/Order/GeneralTextInformation[@name 

Situation']/GentextTextIndicator/@contextId"/> 

</Context.id  > 

<ContextAssessingOrganisation.id  > 

<xsl: value- of  select="/Order/ExerciseIdentification/@actionIdNumber"/> 
</ContextAssessingOrganisation.id  > 

<updateSequencel\lumber>777771234567890</updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</ContextAssessment  > 

</xsl :  if  > 

<xsl : if  test="/Order/GeneralTextInformation[@name  =  'Mission']  "> 

<ContextAssessment  > 

<ContextAssessment.index>1001</ContextAssessment.index> 


205 


<ContextAssessment.effectiveTime  ></ContextAssessment.effectiveTime  > 
<ContextAssessment.effectiveDatex/ContextAssessment.effectiveDate> 

<ContextAssessment.text  ><xsl:value-of  select="/Order/GeneralTextInformation[(g)name 

Mission' ]/FreeText  "/> 

</ContextAssessment.text  > 
cContext.id  > 

<xsl: value- of  select="/Order/GeneralTextInformation[@name  =  'Mission']/GentextTextIndicator/@contextId"/> 
</Context.id  > 

<ContextAssessingOrganisation.id  > 

<xsl: value- of  select="/Order/ExerciseIdentification/@actionIdl\lumber"/> 

</ContextAssessingOrganisation.id  > 

<updateSequencel\lumber>77777 1234567890  </updateSequencel\lumber> 

<ownerId  >81234567890</ownerld  > 

</ContextAssessment  > 

</xsl :  if  > 

<xsl : if  test="/Order/GeneralTextInformation[@name  =  'Execution']  "> 

<ContextAssessment  > 

<ContextAssessment.index>1001</ContextAssessment.index> 

<ContextAssessment.effectiveTime  ></ContextAssessment.effectiveTime  > 
<ContextAssessment.effectiveDate></ContextAssessment.effectiveDate> 

<ContextAssessment.text  xxsl: value- of  select="/Order/GeneralTextInformation[@name 

Execution'J/FreeText  "/> 

</ContextAssessment.text  > 

<Context.id  > 

<xsl:  value- of  select="/Order/GeneralTextInformation[@name 

Execution']/GentextTextIndicator/@contextId"/> 

</Context.id  > 

<ContextAssessingOrganisation.id  > 

<xsl: value- of  select="/Order/ExerciseIdentification/@actionIdNumber"/> 

</ContextAssessingOrganisation.id  > 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</ContextAssessment  > 
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</xsl :  if  > 


<xsl : if  test="/Order/GeneralTextInformation[@name  =  'AdminAndLog']  "> 

<ContextAssessment  > 

<ContextAssess  merit.  index>l  00  l</ContextAssessment.index> 

<ContextAssessment.effectiveTime  ></ContextAssessment.effectiveTime  > 
<ContextAssessment.effectiveDate></ContextAssessment.effectiveDate> 

<ContextAssessment.text  xxsl : value-of  select="/Order/GeneralTextInformation[@name 

'AdminAndLog']/FreeText  "/> 

</ContextAssessment.text  > 

<Context.id  > 

<xsl  :value-of  select="/Order/GeneralTextInformation[@name 

'AdminAndLog']/GentextTextIndicator/@contextId"/> 

</Context.id  > 

<ContextAssessingOrganisation.id  > 

<xsl  :value- of  select="/Order/ExerciseIdentification/@actionIdl\lumber"/> 
</ContextAssessingOrganisation.id  > 

<updateSequencel\lumber>77777 1234567890  </updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</ContextAssessment  > 

</xsl :  if  > 

<xsl : if  test="/Order/GeneralTextInformation[@name  =  'AdminAndLog']  "> 

<ContextAssessment  > 

<ContextAssessment.index>1001</ContextAssessment.index> 

<ContextAssessment.effectiveTime  ></ContextAssessment.effectiveTime  > 

<Co  ntextAssessment.  effective  Date  ></ContextAssessment.  effective  Date  > 

<ContextAssessment.text  xxsl: value-of  select="/Order/GeneralTextInformation[@name 

'CommandAndControl']/FreeText  "/> 

</ContextAssessment.text  > 

<Context.id  > 
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<xsl  :value-of  select="/Order/GeneralTextInformation[@name 

'CommandAndContror]/GentextTextIndicator/@contextId"/> 

</Context.id  > 

<ContextAssessingOrganisation.id  > 

<xsl: value- of  select="/Order/ExerciseIdentification/@actionIdl\lumber"/> 
</ContextAssessingOrganisation.id  > 

<updateSequencel\lumber>777771234567890</updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</ContextAssessment  > 

</xsl :  if  > 

</ContextAssessmentTable  > 


</xsl:template> 

<xsl:template  name  ="AssignOR"> 

<ObjectItem> 

<ObjectItem.id xxsl lvalue- of  select="@objectItemIdNumber"/x/ObjectItem.id> 
<ObjectItem.name  > 

<xsl  :value-of  select="@name  "/> 

</ObjectItem.name  > 

<ObjectItem.categoryCode>OR</ObjectItem.categoryCode> 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 
<ownerId  >81234567890</ownerld  > 

</ObjectItem> 

</xsl:template> 

<xsl:template  name  ="AssignFE" > 

<ObjectItem> 

<ObjectItem.id xxsl lvalue- of  select="@objectItemIdNumber"/x/ObjectItem.id> 
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<ObjectItem.name  > 

<xsl  :value-of  select="@name  "/> 

</ObjectItem.name  > 

<ObjectItem.categoryCode>FE</ObjectItem.categoryCode> 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 
<ownerId  >81234567890</ownerld  > 

</ObjectItem> 

</xsl:template> 

<xsl:template  name  ="AssignObjectTypeNumber"> 

<ObjectType> 

<ObjectType.id xxsl lvalue- of  select ="@objectTypeIdNumber"/></ObjectType.id > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 

<ObjectType.name  > 

<xsl  :value-of  select="@name  "/> 

</ObjectType.name  > 

<ObjectType.dummyIndicatorCode>NO</ObjectType.dummyIndicatorCode> 
<ObjectType.categoryCode>OR</ObjectType.categoryCode> 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 
<ownerId  >81234567890</ownerld  > 

</ObjectType> 

</xsl:template> 


<xsl:template  name  ="Organisation "> 

<Organisation  > 

<Organisation.  nickname  Name  xxsl  lvalue- of  select="@name  "/></ Organisation,  nickname  Name  > 
<Organisation.categoryCode>UN</Organisation.categoryCode> 

<Organisation.id> <xsl lvalue- of  select ="@objectItemIdNumber"/x/ Organisation. id > 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</Organisation  > 

</xsl  :template> 
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<xsl:template  name  ="References"> 


<Reference> 

<Reference.id  xxsl:  value- of 

select ="/Order/MessageIdentification/MessageSerialNumber/(g)referenceIdNumber"/></  Reference,  id  > 
<Reference.transmittalTypeCode>TELEX</  Reference.transmittalTypeCode> 

<Reference.sourceText  xxsl:  value- of 

select="/Order/MessageIdentification/Originator/MessageClassification7></Reference.sourceText  > 
<Reference.securityClassificationCodexxsl:value-of 

select ="/Order/MessageIdentification/MessageSerialNumber/@referenceIdNumber"/x/Reference.securityClassificationCode> 
<Reference.identificationText  >Exercise:  <xsl:value-of  select="/Order/ExerciseIdentification/@setid7>;  Exercise 
Nickname:  <xsl:value-of  select="/Order/ExerciseIdentification/ExerciseNickname "/>;  Messageld:  <xsl :value-of 

select="/Order/MessageIdentification/@setid"/>;  Msg  Format:  <xsl:  value- of 

select="/Order/MessageIdentificationMessageTextFormatIdentifier"/>;  Serial  Number:  <xsl:  value- of 

select="/Order/MessageIdentification/MessageSerialNumber"/>;  OrderType:  <xsl:  value- of 

select="/Order/TypeOfOrder/@setid"/>;  Plan  Type;  <xsl:value-of  select="/Order/TypeOfOrder/TypeOfPlanOrder"/>; 

Authority:  <xsl: value- of  select=70rder/OrderReference/OrderOriginatorAndOrNumber/MilitaryCommandAuthority7>; 

OpOrderNr:  <xsl : value- of  select="/Order/OrderReference/OrderOriginatorAndOrNumber/OperationOrderNumberV> 

</ Reference. identificationText  > 

<Reference.formatCode>  <xsl:  value- of 

select="/Order/MessageIdentification/MessageFormat  "/></ Reference. formatCode> 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerId  >8 1 234567890  </ownerId  > 

</  Reference> 

</xsl  :template> 

<xsl:template  name  ="AssignObjectItemTypeIndex"> 

<ObjectItemType> 

<ObjectItemType.index>33300001</ObjectItemType.index> 

<ObjectItem. id  xxsl: value- of  select="@objectItemIdNumber"/x/ObjectItem.id> 

<ObjectType.id xxsl: value- of  select ="@objectTypeIdNumber7></ObjectType.id > 

<ReportingData.id  >22220001  </  Reporting  Data,  id  > 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<owner!d  >81234567890</ownerld  > 
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</ObjectItemType  > 

</xsl  :template> 

<xsl:template  name  ="FeatureTableIdl\lumber"> 

<Feature  > 

<Feature.categoryCode  >CF  </Feature.categoryCode  > 

<Feature.idxxsl: value- of  select ="@objectItemIdNumber"/></Feature. id > 
<updateSequencel\lumber>777771234567890</updateSequencel\lumber> 
<ownerId  >8 1 234567890  </ownerId  > 

</ Feature  > 

</xsl  :template> 

<xsl:template  name  ="LocationTableIdNumber"> 

<Location  > 

<Location.idxxsl: value- of  select  ="@locationIdNumber"/x/Location.id> 
<Location.categoryCode>PT  </Location.categoryCode> 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 
<ownerId  >81234567890</ownerld  > 

</Location  > 

</xsl  :template> 

<xsl:template  name  ="FeatureLocationTableNumber"> 

<FeatureLocation  > 

<FeatureLocation.index> 

<xsl:  value- of  se  lect ="@featu  relocation  I  ndexNumber"/> 
</FeatureLocation.index> 

<FeatureLocation.accuracyQuantity>0  </FeatureLocation.accuracyQuantity> 
<Location.idxxsl: value- of  select  ="@locationIdNumber"/x/Location.id> 
<Feature.idxxsl : value- of  select ="@objectItemIdNumber"/x/Feature. id > 
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<ReportingData.id  >22220002  </  Reporting  Data,  id  > 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</FeatureLocation  > 

</xsl:template> 

<xsl:template  name  ="PointTableIdNumber"> 

<Point  > 

<Point.verticalPrecisionCode>10M</Point.verticalPrecisionCode> 
<Point.horizontalPrecisionCode>10M  </Point.horizontalPrecisionCode> 
<Point.categoryCode>ABS  </Point.categoryCode> 

<Point.id xxsl lvalue- of  select ="@locationIdNumber"/x/Point. id  > 
<updateSequencel\lumber>777771234567890</updateSequencel\lumber> 

<ownerId  >81234567890</ownerld  > 

</Point  > 

</xsl  :template> 

<xsl:template  name  ="AbsolutePointTableIdNumber"> 

<AbsolutePoint  > 

<AbsolutePoint.longitudeCoordinate> 

<xsl lvalue- of  se lect ="@ longitude "/> 

</AbsolutePoint.longitudeCoordinate> 

<AbsolutePoint.latitudeCoordinate> 

<xsl :value-of  select="@latitude"/> 

</AbsolutePoint.latitudeCoordinate> 

<AbsolutePoint.elevationCategoryCode>LOC</AbsolutePoint.elevationCategoryCode> 
<AbsolutePoint.id  xxsl  lvalue- of  select="@locationIdNumber"/x/ Absolute  Point,  id  > 
<updateSequenceNumber>777771234567890</updateSequencel\lumber> 

<ownerId  >81234567890</ownerld  > 

</AbsolutePoint  > 


</xsl  :template> 
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<xsl:template  name  ="ActionIdNumber"> 

<Action  > 

<Action.id  xxsl: value- of  select ="@actionIdNumber"/x/Action. id  > 

<Action.name  xxsl: value- of  select="@actionDescription"/x/ Action. name  > 
<Action.categoryCode  >ACTTA</  Action.  categoryCode> 

<updateSequencel\lumber>777771 234567890  </updateSequencel\lumber> 

<ownerId  >81234567890</ownerld  > 

</ Action  > 

</xsl  :template> 

<xsl:template  name  ="CandidateTargetIndexNumber"> 

<CandidateTargetDetail  > 

<CandidateTa  rgetDetail.index> 

<xsl  :value- of  select ="@candidateTargetDetailIndexl\lumber"/> 

</CandidateTargetDetail.index> 

<CandidateTargetDetail.schemeCode>SITEI\IR</CandidateTargetDetail.schemeCode> 

<CandidateTargetDetail.priorityQuantity>l</CandidateTargetDetail.priorityQuantity> 

<Ca  nd  idateTarget  Detail.  labelText/> 

<CandidateTargetDetail.focusTypeCode>NOS</CandidateTargetDetail.focusTypeCode> 
<CandidateTargetDetail.discriminatorCode>CTDITM</CandidateTargetDetail.discriminatorCode> 
<CandidateTargetList.id  > 

<xsl  :value-of 

select="/Order/Ge  neralTextInformation/CoordinatingInstructions/MissionObjectiveLocation/@targetIdNumber"/> 
</CandidateTargetList.id  > 

<updateSequencel\lumber>777771234567890</updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</CandidateTargetDetail  > 

</xsl  :template> 

<xsl:template  name  ="TargetDetailItemNumber"> 
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<CandidateTargetDetailItem> 

<CandidateTa  rgetDetail.index> 

<xsl lvalue- of  select="@candidateTargetDetailIndexl\lumber"/> 

</CandidateTargetDetail.index> 

<CandidateTargetList.id  > 

<xsl:value-of 

select ="/Order/GeneralTextInformation/CoordinatingInstructions/MissionObjectiveLocation/(g)targetIdNumber"/> 
</CandidateTargetList.id  > 

<ObjectItem.id xxsl lvalue- of  select="@objectItemIdNumber"/x/ObjectItem.id> 
<updateSequencel\lumber>77777 1234567890  </updateSequencel\lumber> 

<ownerId  >81234567890</ownerld  > 

</CandidateTa  rgetDetailItem> 

</xsl  :template> 

<xsl:template  name  ="ActionTaskReferenceTable "> 

<  Actio  nTask> 

<ActionTask.plannedEndTime  x/ActionTask.plannedEndTime  > 

<ActionTask.minimumDuration  >0  </ActionTask.  minimum  Du  ration  > 
<ActionTask.estimatedDuration>0</ActionTask.estimatedDuration> 

<ActionTask.  maximum  Du  ration  >0</ActionTask.  maximum  Duration  > 
<ActionTask.plannedStartDatexxsl  lvalue- of  select ="@ju  Man  Date"/ > 

</ActionTask.plannedSta  rtDate> 

<ActionTask.plannedStartTime  xxsl :value-of  select="@startTimeInSecondsPerDay"/> 
</ActionTask.plannedStartTime  > 

<ActionTask.startPrecisionCode>HR</ActionTask.startPrecisionCode> 

<ActionTask.categoryCode>ORD</ActionTask.categoryCode> 

<ActionTask.  planned  End  Date  x/ActionTask.  planned  End  Date  > 
<ActionTask.endPrecisionCode>HR</  Actio  nTask.  end  Precision  Code  > 
<ActionTask.endQualifierCode>NLT  </ActionTask.endQualifierCode> 

<ActionTask.priorityCode>l  </ActionTask.priorityCode> 

<ActionTask.verbPhraseCodexxsl lvalue- of  se lect="@action "/></ ActionTask. verbPhraseCode> 
<ActionTask.startQualifierCode>NLT  </ActionTask.startQualifierCode> 
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<ActionTask.id  xxsl : value- of  select  ="@actionIdN umber"/x/ActionTask. id > 

<CandidateTargetl_ist.id  >  <xsl:  value- of 

select="/Order/GeneralTextInformation/CoordinatingInstructions/MissionObjectiveLocation/@targetIdNumber"/></CandidateTa 
rgetList.id  > 

<updateSequencel\lumber>777771234567890</updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</ActionTask> 

</xsl  :template> 

<xsl:template  name  ="ActionFunctionalAssociationIndexNumber"> 

<ActionFunctionalAssociation  > 

<Action  Functional  Association,  index  >33 1234500001  </ActionFunctionalAssociation.index> 
<ActionFunctionalAssociation.categoryCode>FISA</ActionFunctionalAssociation.categoryCode> 

<ObjectAction.id  > 

<xsl : value- of  select="/Order/ExerciseIdentification/@actionIdl\lumber"/> 

</ObjectAction.id  > 

<SubjectAction.id xxsl: value- of  select ="@actionIdNumber"/x/SubjectAction. id > 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</ActionFunctionalAssociation  > 

</xsl  :template> 

<xsl:template  name  ="ActionResourceItemTableIndex"> 

<ActionResource> 

<ActionResource.index>331 23456000 1</  Action  Resource.index> 

<ActionResource.qualifierCode  >AUTFI</ActionResource.qualifierCode> 
<ActionResource.criticalityIndicatorCode>YES  </ActionResource.criticalityIndicatorCode> 
<ActionResource.categoryCode>RI  </ActionResource.categoryCode> 

<Action.id xxsl: value- of  select ="@actionIdNumber"/x/Action. id > 

<AuthorisingOrganisation.id  > 
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<xsl  :value-of 

select=yOrder/OrderReference/OrderOriginatorAndOrl\lumber/MilitaryCommandAuthority/@objectItemIdNumber,,/> 

</AuthorisingOrganisation.id  > 

<updateSequenceNumber>777771234567890</updateSequencel\lumber> 

<ownerId  >81234567890</ownerld  > 

</ActionResource> 

</xsl  :template> 

<xsl:template  name  ="LinkingActionId20bjectItemIdNumber"> 

<ActionResourceItem> 

<ActionResource.index>331 23456000  l</ActionResource.index> 

<Action.id  xxsl : value- of  select="@actionIdl\lumber"/x/ Action,  id  > 

<0bjectltem.id  >  <xsl  lvalue- of 

select="/Order/GeneralTextInformation/Tasks/Organization/MarineExpeditionary  Unit/Battalion  La  ndingTea  m/Com  pa  ny[@  name 
'AAAV  Company']/@objectltemldl\lumber"/x/0bjectltem.id > 

<updateSequencel\lumber>77777 1234567890  </updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</ActionResourceItem> 

</xsl:template> 

<xsl:template  name  ="ActionObjectiveTable"> 

<ActionObjective> 

<ActionObjective.index>441 234567001  </ActionObjective.index> 

<ActionObjective.priorityCode>l  </ActionObjective.priorityCode> 

<ActionObjective.qualifierCode>AUTH</ActionObjective.qualifierCode> 

<ActionObjective.categoryCode>OI</ActionObjective.categoryCode> 

<Action.  id  xxsl  lvalue- of  select ="@actionIdl\lumber"/x/Action.  id  > 

<AuthorisingOrganisation.id  > 
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<xsl  :value-of 

select=yOrder/OrderReference/OrderOriginatorAndOrl\lumber/MilitaryCommandAuthority/@objectItemIdNumber,,/> 

</AuthorisingOrganisation.id  > 

<updateSequenceNum  be  r>777771 234567890  </updateSequenceNumber> 

<ownerId  >81234567890</ownerld  > 

</ActionObjective> 

</xsl:template> 

<xsl template  name  ="ActionObjectiveItemCrossReferenceTable"> 

<ActionObjectiveItem> 

<ActionObjectiveItem.categoryCode>NOS</ActionObjectiveItem.categoryCode> 
<ActionObjective.index>441 234567001  </ActionObjective.index> 

<Action.id  xxsl: value- of  select="@actionIdl\lumber"/x/ Action,  id  > 

<0bjectltem.id xxsl lvalue- of  select="@objectItemIdNumber"/x/ObjectItem.id> 
<CandidateTargetList.id  > 

<xsl  :value-of 

select =''/Order/GeneralTextInformation/CoordinatingInstructions/MissionObjectiveLocation/(g)targetIdNumber"/> 
</CandidateTargetList.id  > 

<CandidateTa  rgetDetail.indexxxsl  lvalue- of 
select="@candidateTargetDetailIndexl\lumber"/x/CandidateTargetDetail.index> 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerId  >8 1 234567890  </ownerId  > 

</ActionObjectiveItem> 

</xsl  :template> 

<xsl:template  name  ="ContextTableNumbers "> 

<Context  > 

<Context.id xxsl:value-of  select="@contextId"/x/Context.id > 

<Context.name  xxsl:value-of  select=". "/x/Context.name  > 

<updateSequencel\lumber>77777 1234567890  </updateSequencel\lumber> 

<owner!d  >81234567890</ownerld  > 
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</Context  > 


</xsl:template> 

<xsl:template  name  ="ActionContextReference"> 

<ActionContext  > 

<ActionContext.index>1001</ActionContext.index> 

<ActionContext.categoryCode  >DES  </ActionContext.categoryCode  > 

<Context.id ><xsl:value-of  select="@contextId"/x/Context.id > 

<Action.id  xxsl: value- of  select ="/Order/ExerciseIdentification/@actionIdNumber"/> 
</ Action,  id  > 

<updateSequencel\lumber>777771234567890</updateSequencel\lumber> 

<ownerId  >81234567890</ownerld  > 

</ActionContext  > 

</xsl  :template> 


</xsl:stylesheet> 
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APPENDIX  N.  AMPHIBIOUS-RAID  CODE 


A.  INTRODUCTION 

This  appendix  contains  scripted  code  for  the  amphibious -raid.  This  code  is  available  at 
http://web.nps.navy.mil/~brutzman/Savage/Scenarios/CampPendletonCalifornia/AmphibiousRaid 

B.  AMPHIBIOUS -RAID  CODE 

<?xml  version="  1 .0"  encoding="UTF-8"?> 

<!DOCTYPE  X3D  PUBLIC  "http://www.web3D.org/TaskGroups/x3d/translation/x3d-compact.dtd" 
"file:///C:/www.web3D.org/TaskGroups/x3d/translation/x3d-compact.dtd"> 

<X3D> 

<head> 

cmeta  name=' filename '  content= ' <Amphibiou sRa  id. xml> '  /> 
cmeta  name='description'  content= 'Amphibious  Raid  shows  an  exemplar  amphibious  raid  at  Red  Beach,  Camp 
Pendleton  California.  It  is  the  primary  scenario  for  the  SAVAGE  group.  '/> 

<meta  name='author'  content='Don  Brutzman,  Curtis  Blais,  Jeff  Weekley,  Jane  Wu,  Shane  Nicklaus,  Mike 
Hunsberger'/> 

cmeta  name='created'  content='9  April  200 1  V> 
cmeta  name=' revised'  content='27  July  2001  '/> 

cmeta  name='reference'  content ='cNpsRedBeachRaidScenario2001May2.html>7> 
cmeta  name=' reference'  content ='cNpsRedBeachRaidScenario2001May2.ppt>'/> 
cmeta  name='image'  content='cHeloPatrolPendletonBackground.png>  7> 
cmeta  name='reference'  content ='cAmphibiousRaidWithCommunications.xml>'/> 
cmeta  name=' warning'  content='Coordinate  system  axes  need  to  be  aligned  properly. '/> 
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cmeta  name='url' 

content = '<http://web.nps.navy.mil/~brutzman/Savage/Scenarios/CampPendletonCalifomia/AmphibiousRaid.xml> '/> 
<meta  name='reference' 

content = '<http://web.nps.navy.mil/~brutzman/Savage/Tools/Animation/WavpointInterpolator.xml>  '/> 

<meta  name=' generator'  content ='X3D- Edit,  <http://www.web3D.org/TaskGroups/x3d/translation/README.X3D- 
Edit.html>'/> 

</head> 

<Scene> 


<!--  Prototype  and  external  prototype  declarations  must  precede  scene  definition  --> 

<ExtemProtoDeclare  name= '  Hidden V ie wpoint ' 

url=' "../.  ./Tools/ Animation/HiddenViewpointPrototype.wrl#HiddenViewpoint 

<../■  ./Tools/ Animation/HiddenViewpointPrototype.wrl>" 

'’http://web.nps.navy.mi1/~brutzman/Savage/Tools/Animation/HiddenViewpointPrototype.wrl#HiddenViewpoint 

<http://web.nps.navv.mil/~brutzman/Savage/Tools/Animation/HiddenViewpointPrototype.wrl>" 

"■■/■■/Tools/Animation/HiddenViewpointPrototype.xml#HiddenViewpoint 

<■■/.  ./Tools/ Animation/HiddenViewpointPrototype.xml>" 

"http  ://web  .nps  .navy  .mil/~brutzman/S  avage/Tools/Animation/Hidde  nV  ie  wpointPrototype  .xml#HiddenViewpoint 

<http://web.nps.navy.mil/~bmtzman/Savage/Tools/Animation/HiddenViewpointPrototvpe.xml>'"> 

<field  name= 'position'  type='Vector3 Float'  vrml97Hint='exposedField'/> 

<field  name= 'rotation'  type =' Rotation'  vrml97Hint='exposedField7> 

<field  name='sensorRadius'  type='Float'  vrml97Hint='field'/> 

<field  name=  'label'  type='Strings'/> 

<field  name='labelOffset'  type='Vector3Float'  vrml97Hint='exposedField'/> 

<field  name='labelFontSize'  type='Float'  vrml97Hint=' field '/> 

<field  name='labelColor'  type='Color'  vrml97Hint='exposedField7> 

</ExternProtoDeclare> 

<ExtemProtoDeclare  n  a  m  e = '  W  ay  p  o  i  n  1 1  n  t  e  rp  o  1  a  to  r '  nodeTypeHint= 'Group ' 

url=' " . ./.  ./T  ools/Animation/W  aypointlnterpolatorPrototype.  wrl#W  aypointlnterpolator 
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<../../Tools/Animation/W  aypointInterpolatorPrototype.wrl> " 

"http  ://web  .nps  .navy  .mil/~brutzman/S  avage/T  ools/Animation/W  aypointlnterpolatorPrototype.  wrl#W  aypointlnterpolato 

r  <http://web.nps.navy.mil/~brutzman/Savage/Tools/AnimationAVaypointInterpolatorPrototype.wrl>1’ 

"■■/■■/Tools/Animation/WaypointInterpolatorPrototype.xml#WaypomtInterpolator 

<../../Tools/AnimationAVaypointInterpolatorPrototype.xml>'’ 

'’http://web.nps.navv.mi1/~brutzman/Savage/Tools/AnimationAVaypointInterpolatorPrototvpe.xml#WaypointInterpolat 

or  <http://web.nps.navy.mil/~brutzman/Savage/Tools/Animation/WaypointInterpolatorPrototype.xml>'"> 

<field  name= 'wayPoints'  type='Vector3FloatArray'  vrml97Hint='field'/> 

<field  name='pitchUpDownForVerticalWay Points'  type=' Boolean'  vrml97Hint  =' field '/> 

<!--  Priority  of  use:  legSpeeds  (m/sec),  legDurations  (seconds),  defaultSpeed  (m/sec)  --> 

<!--  If  used,  array  lengths  for  legSpeeds  and  legDurations  must  be  one  less  than  number  of  wayPoints.  --> 

<field  name=' legSpeeds'  type='Floats '  vrml97Hint=' field '/> 

<field  name=  'legDurations '  type='Times'  vrml97Hint=' field' /> 

<field  name=  'defaultSpeed'  type='Float'  vrml97Hint='field'/> 

<!--  turningRate  (degrees/second)  will  also  determine  standoff  distance  prior  to  waypoint  where  turn 
commences.  If  0,  turns  are  instantaneous.  --> 

<field  name=  'turningRate'  type='Float'  vrml97Hint='field'/> 

<field  name='totalDuration'  type='Time'  vrml97Hint='eventOut'/> 

<!--  exposed  Positionlnterpolator  and  Orientationlnterpolator  settings:  --> 

<field  name=' fraction'  type='Float'  vrml97Hint='eventIn7> 

<field  name='positionValue'  type ='Vector3 Float'  vmil97Hint='eventOut7> 

<field  name='orientationValue '  type= 'Rotation'  vrml97Hint='eventOut'/> 

<field  name='lineColor'  type='Color'  vrml97Hint='exposedField'/> 

<!--  highlightSegmentColors  must  contain  two  color  values,  for  each  endpoint  of  the  highlight  segment.  --> 

<field  name=' highlightSegmentColors'  type='Colors'  IS='HighlightSegmentColorNode. color' 
vrml97Hint='exposedField '  /> 

<field  name=  'transparency'  type='Float'  vrml97Hint='exposedField'/> 

<field  name=7abelOffset'  type='Vector3Float'  vrml97Hint='field'/> 

<field  name='labelFontSize'  type='Float'  vrml97Hint=' field '/> 

<field  name='labelColor'  type='Color'  vrml97Hint=' field '/> 
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<field  name='traceEnabled' type= 'Boolean'  vrml97Hint=' field  '/> 


</ExternProtoDeclare> 

<ExtemProtoDeclare  name='ViewPositionOrientation' 

url='  "■■/■■/Tools/Authoring/ViewPositionOrientationPrototype.wrl#ViewPositionOrientation 

<../../Tools/Authoring/ViewPositionOrientationPrototype.wrl>" 

"http://web.nps.navy.mi1/~brutzman/Savage/Tools/Authoring/ViewPositionOrientationPrototype.wrl#ViewPositionOri 

entation  <http ://web .nps .navy .mil/ ~brutzman/Savage/T ools/Authoring/ViewPositionOrientationPrototype . wrl> " 

"■■/■■/Tools/Authoring/ViewPositionOrientationPrototype.xml#ViewPositio  nOrientation 

<../../Tools/Authoring/ViewPositionOrientationPrototype.xml>" 

'’http://web.nps.navv.mi1/~brutzman/Savage/Tools/Authoring/ViewPositionOrientationPrototype.xml#ViewPositionOri 

entation  <http://web.nps.navy.mil/~brutzman/Savage/Tools/Authoring/ViewPositionOrientationPrototype.xml>"'> 

<field  name= 'enabled' type =' Boolean'  vrml97Hint='exposedField7> 

</ExternProtoDeclare> 

<ExtemProtoDeclare  name='CameraCompass36' 

url='  "■■/■■/Tools/HeadsUpDisplavs/CameraCompassPrototypes.wrl#CameraCompass36 

<../../Tools/HeadsUpDisplays/CameraCompassPrototypes.wrl>" 

"http://web.nps.navy.mi1/~brutzman/Savage/Tools/HeadsUpDisplays/CameraCompassPrototypes.wrl#CameraCompass 

36  <http://web.nps.navy.mil/~brutzman/Savage/Tools/HeadsUpDisplays/CameraCompassPrototypes.wri>" 

"■■/■■/Tools/HeadsUpDisplavs/CameraCompassPrototypes.xml#CameraCompass36 

<../../Tools/HeadsUpDisplays/CameraCompassPrototypes.xml>" 

"http://web.nps.navy.mi1/~brutzman/Savage/Tools/HeadsUpDisplays/CameraCompassPrototypes.xml#CameraCompas 

s36  <http://web.nps.navy.mil/~brutzman/Savage/Tools/HeadsUpDisplavs/CameraCompassPrototypes.xml>'"> 

<field  name= 'enabled'  type =' Boolean'  vrml97Hint='exposedField'/> 

<field  name='positionOffsetFromCamera'  type='Vector3Float'  vrml97Hint='exposedField'/> 

<field  name='markerColor'  type='Color'  vrml97Hint='exposedField'/> 

<field  name='labelColor'  type='Color'  vrml97Hint='exposedField7> 

</ExternProtoDeclare> 
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<ExtemProtoDeclare  name=' AH  1  SuperCobra'  nodeTypeHint=' Group'  url=' ./AircraftHelicopters/AH  1  SuperCobra- 
UnitedStates/S  uperCobraPrototype.wrl#SuperCobra  <../.  ./AircraftHelicopters/AH  lSuperCobra- 

UnitedStates/SuperCobraPrototype.wrl>'’ 

"http://web.nps.navy.mil/~brutzman/Savage/AircraftHelicopters/AHlSuperCobra- 

UnitedStates/SuperCobraPrototype.wrl#SuperCobra 

<http://web.nps.navy.mil/~brutzman/Savage/AircraftHelicopters/AHlSuperCobra- 

UnitedStates/SuperCobraPrototype.wrl>"  ", ./.  ./AircraftHelicopters/AH  1  SuperCobra- 
UnitedStates/SuperCobraPrototype .xml#SuperCobra  ./AircraftHelicopters/AH  1  SuperCobra- 

UnitedStates/SuperCobraPrototype.xml>" 

"http  ://web  .nps  .navy  .milZ-brutzman/S  av  age/ AircraftHelicopters/AH  1  SuperCobra- 

UnitedStates/SuperCobraPrototype.xml#SuperCobra 

<http :  //web .  nps .  navy.mil/~brutzman/S  avage/ AircraftHelicopters/AH  1  SuperCobr  a- 

UnitedStates/SuperCobraPrototype.xml>'"> 

<freld  name='tailBoomColor'  type='Node'  vrml97Hint=' field '/> 

<field  name='tailRotorDriveShaftColor'  type='Node'  vrml97Hint='field7> 

<field  name='horizontalStabilizerColor'  type='Node'  vrml97Hint='field7> 

<field  name='fuselageColor'  type='Node'  vrml97Hint=' field 7> 

<field  name='cockpitColor'  type='Node'  vrml97Hint=' field '/> 

<field  name='cowlingColor'  type='Node'  vrml97Hint='field7> 

<field  name='helicopterName'  type='String'  vrml97Hint='field7> 

<field  name='inFlight'  type=' Boolean'  vrml97Hint='eventIn'/> 

</ExternProtoDeclare> 

<!--  =================  -> 

<NavigationInfo  avatarS ize  ='2  2  2'  speed='100'  type='EXAMINE  ANY  visibilityLimit='60000'/> 

<Background  groundAngle=' 1.309,  1.571 '  groundColor='0  0.2  0.4,  0.05  0.25  0.6,  0.1  0.2  0.4'  sky Angle='  1.309,  1.571' 
skyColon'0.1  0.1  0.4,  0.1  0.125  0.4,  0.1  0.1  0.3  7> 

<Viewpoint  description' Amphibious  raid  -  full  scenario  seen  from  above'  orientation='-0.557  -0.799  -0.229  0.9506' 
position='-600  10000  25000'/> 

<Viewpoint  description' 1000m  elevation  view'  orientation'O  1  0  -0.78'  position'-200  1000  22000'/> 
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cTransform  rotation='0  0  1  . 1  ’> 


cViewpoint  description='Waypoint'  orientation='0  1  0  1.57'  position='9451  20  14935  7> 
<Viewpoint  description^ waypoint  2'  orientation='()  1  0  1.57'  positional  1217.2  10.0  13996. 6'/> 

</Transform> 

<!--  ViewPositionOrientation  is  a  prototype  lets  us  find  good  viewpoints  for  inclusion  in  the  scene  --> 
<ProtoInstance  name='ViewPositionOrientation'> 

<fieldValue  name =' enabled'  value='tme'/> 

</ProtoInstance  > 

<!--  This  is  a  hack  to  orient  camera  to  scene.  Actually,  scene  elements  need  to  be  rotated.  --> 
cTransform  rotation='0  1  0  1.57'> 

cProtoInstance  name='CameraCompass36'> 

cfieldValue  name= 'enabled'  valuc='true7> 
cfieldValue  name='positionOffsetFromCamera'  value='0  5  0'/> 
cfieldValue  name='markerColor'  value='0.9  0.9  0.9 '/> 
cfieldValue  name='labelColor'  value='0.9  0.9  0.9 '/> 

c/ProtoInstance> 

c/Transform> 

cProtoInstance  DEF = '  CobraC apS tartingPoint '  name = '  Hidden V ie wpoint '> 

cfieldValue  name='position'  value='6530  18  16800'/> 
cfieldValue  name= 'rotation'  value='0  1  0  -0.1  '/> 
cfieldValue  name='sensorRadius '  value='1007> 

cfieldValue  name=' label'  value='" Cobra  CAP"  "starting  point"  ""  "6530  11.5  16800"7> 
cfieldValue  name='labelOffset'  value='0  -2  0'/> 
cfieldValue  name='labelFontSize'  value='0.5'/> 
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<fieldValue  name='labelColor'  value='l  0.5  0'/> 


</ProtoInstance> 

<ProtoInstance  DEF='CobraCapInitialClimb'  name='HiddenViewpoint  '> 

<fieldValue  name= 'position'  value='6530  500  16800 '/> 

<fieldValue  name= 'rotation'  value='0  1  0  -0.4'/> 

<fieldValue  name='sensorRadius '  value='100'/> 

<fieldValue  name='label’  value='"Cobra  CAP"  "initial  climb  point . 6530  500  16800"'/> 

<fieldValue  name='labelOffset'  value='0  1  0'/> 

<fieldValue  name='labelFontSize'  value='0.5'/> 

<fieldValue  name='labelColor'  value='l  0.5  0 '/> 

</ProtoInstance> 

<ProtoInstance  DEF='SouthemCapTurnPoint'  name='HiddenViewpoint'> 

<fieldValue  name='position'  value='25400  500  191 00 '/> 

<fieldValue  name= 'rotation'  value='0  1  0  0.4'/> 

<fieldValue  name='sensorRadius'  value='200'/> 

<fieldValue  name='label'  value='"Cobra  CAP"  "Southern  Turn  Point" . 25400  500  191000"'/> 

<fieldValue  name='labelOffset'  value='0  1  0'/> 

<fieldValue  name='labelFontSize'  value='0.5'/> 

<fieldValue  name='labelColor'  value='l  0.5  0 '/> 

</ProtoInstance  > 

<ProtoInstance  DEF='NorthemCapTurnPoint '  name='HiddenViewpoint'> 

<fieldValue  name= 'position'  value='5100  500  700 '/> 

<fieldValue  name= 'rotation'  value='0  1  0  -2.3 '/> 

<fieldValue  name='sensorRadius '  value='200'/> 

<fieldValue  name=Tabel'  value='"Cobra  CAP"  "Northern  Turn  Point"  ""  "5100  500  700"' /> 
<fieldValue  name='labelOffset'  value='0  1  0'/> 
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<fieldValue  name='labelFontSize'  value='0.5'/> 

<fieldValue  name='labelColor'  value='l  0.5  ()'/> 

</ProtoInstance> 

<S  witch  whichChoice='0'> 

<!--  Main  group  with  all  players.  --> 

<Group  DEF='EntireScene'> 

<!-.  ====================  Land  terrain  ====================  --> 

<Transform> 

<Inline 

url='  "<. ./.  ./Locations/CampPendletonCalifornia/CampPendletonOperatingAreasExample.  wrl> " 

'’<http://web.nps.navy.mil/~brutzman/Savage/Locations/CampPendletonCalifornia/CampPendlet 

onOperatingAreasExample.  wrl> " 

"<. ./.  ■/Locations/CampPendletonCalifornia/CampPendletonOperatingAreasExample.xml> " 

"<http://web.nps.navy.mil/~brutzman/Savage/Locations/CampPendletonCalifornia/CampPendlet 

onOperatingAreasExample.xml>"7> 

</Transform> 

<!--  ====================  Ships  ====================  --> 

<!--  LPD  is  anchored  and  not  moving.  --> 

<TransformDEF='LPD'  translation='6600  10  16800 '> 

<Inline  url= '  "<../. ■/Ships/LandingPlatformDock-LPD/LPD.wrl> " 

"<http  ://web  .nps  .navy  .mil/ -brutzman/S  avage/Ships/LandingPlatformDock-  LPD/LPD .  wrl> " 

"<. ./.  ■/Ships/LandingPlatformDock-LPD/LPD.xml> " 

"<http://web.nps.navy  ■mil/~brutzman/Savage/Ships/LandingPlatformDock-LPD/LPD.xml>"7> 

</Transform> 

<!--  ====================  Amphibious  vehicles  ====================  --> 

<!—  AAAV-1  Block -> 
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cTimeSensor  DEF='AAAVl_Clock'  loop='true'/> 

<ROUTE  fromNode='AAAVl_Clock'  fromField='fraction_changed' 
toNode='AAAV_l_WaypointInterpolator'  toField='fraction'/> 

<ROUTE  fromNode='AAAV_l_WaypointInterpolator'  fromField='totalDuration' 
toNode='AAAV l_Clock'  toField='cycleIntervalV> 

<ProtoInstance  DEF = '  A  A  A  V_  1  _W  aypointlnterpolator'  name= '  W  aypointlnterpolator  '> 

<!--  need  to  improve  elevations  on  beach  (final  waypoint)  --> 

<fieldValue  name=' wayPoints'  value='6802  1  16343  7685.0  1.0  15873.7,  8568.1  1.0  15404.4, 
9451.1  1.0  14935.2,  10334.2  1.0  14465.9,  11217.2  1.0  13996.6,  12100.3  1.0  13527.3,  12983.3 
1.0  13058.0,  13866.4  1.0  12588.7,  14749.4  1.0  12119.5,  15632.5  1.0  11650.2,  16515.5  1.0 
11180.9,  17398.6  1.0  10711.6,  18281.6  1.0  10242.3,  19164.7  1.0  9773.1,  19400.0  1.0  9648.0, 

19782  1  9185  20100  10  8800'/> 

<!--  1  knot  =  0.514444444  meters/second  --> 

<fieldValue  name='defaultSpeed'  value ='50  7> 

<fieldValue  name='lineCobr'  value='0.8  0.8  0'/> 

<fieldValue  name='labelColor'  value='0.8  0.8  0'/> 

<fieldValue  name='labelOffset'  value='0  3  0'/> 

<fieldValue  name='labelFontSize'  value='1.5'/> 

<fieldValue  name='traceEnabled'  value =' false  7> 

</ProtoInstance> 

<ROUTE  fromNode='AAAV_l_WaypointInterpolator'  fromField='positionValue'  toNode='AAAV- 
Focation'  toField='  set_translation'/> 

<ROUTE  fromNode='AAAV_l_WaypointInterpolator'  fromField=' orientation  Value'  toNode='AAAV- 
Focation'  toField='  set_rotation'/> 

<!--  Most  entity  transforms  will  get  converted  to  DIS-Java-VRMF  EspduTransforms  when  creating  a 
networked  DIS  version.  --> 
cTransform  translation  '6600  0  16800'/> 

<EspduTransformDEF='AAAV-Focation'  readlnterval='0'  traceOffset='0  4  O'  traceSize='2  2  2' 
translatiorp='6600  0  16800'  writelnterval='l'> 
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<Group> 


cViewpoint  dcscriptioii=' AAAV  raid  from  behind'  orientation='0  1  0  -1.57' 
position='-40  2  0'/> 

<Viewpoint  description='AAAV  raid  from  ahead'  orientation='0  1  0  1.57'  position='50 
12  0'/> 

<TransformDEF='VerticalCorrection'  translation='0  -4  0'> 

<Inline  DEF='AAAV' 

url='  "<. ./.  ./Amphibious  Vehicles/AAAV/AAAV.wrl> " 

'’<http://web.nps.navv.mil/~brutzman/Savage/AmphibiousVehicles/AAAV/AAA 

V.wrl>"  "<. ./.  ./Amphibious Vehicles/AAA V/AAAV.xml> " 
"<http://web.nps.navy.mil/~brutzman/Savage/AmphibiousVehicles/AAAV/AAA 

V.xml>"'/> 


</Transform> 

<Group  DEF='OtherAAAVs'> 

<Transform  translation '-15  -4  15'> 

<Transform  DEF=' AAAV-2'> 

<Inline  USE='AAAV'/> 

<PositionInterpolator  DEF='AAV-2PATH'  key='0.00,  0.11,  0.17, 
0.22,  0.33,  0.44,  0.50,  0.55,  0.66,  0.77,  0.83,  0.88,  0.99' 
keyValue='0.0  0.0  0.0,  1.0  0.96  1.0,  1.5  0.21  1.5,  2.0  0.96  2.0,  3.0 
0.0  3.0,  2.5  0.96  3.0,  1.75  0.41  3.0,  1.0  0.96  3.0,  3.0  0.0  3.0,  2.0 
0.46  2.0,  1.0  0.4  1.5,  0.0  0.46  1.0,  0.0  0.0  0.0'/> 

<ROUTE  fromNode='AAV-2PATH'  fromField='value_changed' 
toNode='AAAV-2'  toField='set_translation'/> 

</Transform> 
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</Transform> 

<Transform  translation^'- 1 5  -4  -17.5'> 

<Transform  DEF=' AAAV-3'> 

<Inline  USE='AAAV'/> 

<PositionInterpolator  DEF='AAV-3PATH'  key='0.00,  0.07,  0.13, 
0.22,  0.36,  0.47,  0.55,  0.625,  0.66,  0.72,  0.80,  0.85,  0.99' 
keyValue='0.0  0.0  0.0,  1.0  0.96  1.0,  1.5  0.21  2.25,  2.0  0.46  2.66, 
3.0  -0.25  3.0,  2.5  0.96  3.0,  1.75  0.41  3.0,  1.0  0.96  3.0,  3.0  0.0  3.0, 
2.0  0.46  2.0,  1.0  0.4  1.5,  0.0  0.46  1.0,  0.0  0.0  0.0'/> 

<ROUTE  fromNode='AAV-3PATEP  fromField='value_changed' 
toNode='AAAV-3'  toField='set_translation7> 

</Transform> 

</Transform> 

</Group> 

</Group> 

</EspduTransform> 

<!--  ====================  Helicopter  1  Block  ====================  --> 

<TransformDEF='Helo-l'  translation='6530  11.5  16800'> 

<ProtoInstance  DEF='HeloInstancel '  name='AHlSuperCobra'> 

<fieldValue  name='helicopterName'  value='Cobra  CAP  l'/> 
<fieldValue  name='tailBoomColor'> 

<Appearance  DEF='  GRE Y_APPE ARAN CE'> 

<MaterialdiffuseColor='0.5  0.5  0.5 '/> 
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</Appearance> 

</fieldValue> 

<fieldV alue  name= 'tailRotorDriveShaftColor '> 

<Appearance  USE=' GRE Y_APPE ARAN CE' /> 
</fieldValue> 

<fieldV alue  name= '  horizontalStabilizerColor'> 
<Appearance> 

<MaterialdiffuseColor='0.5  0.5  0.5 '/> 
</Appearance> 

</fieldValue> 

<fieldV alue  name= '  fuselageColor'> 

<Appearance> 

<MaterialdiffuseColor='0.6  0.6  0.6'/> 
</Appearance> 

</fieldValue> 

<fieldValue  name='cockpitColor'> 

<Appearance> 

<MaterialdiffuseColor='0.6  0.6  0.6'/> 
</Appearance> 

</fieldValue> 
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<fieldValue  name='cowlingColor'> 

<Appearance> 

<MaterialdiffuseColor='0.5  0.5  0.5 '/> 
</Appearance> 

</fieldValue> 

<fieldValue  name='inFlight'  value=' false '/> 
</ProtoInstance  > 


</Transform> 

<ProtoInstance  DEF='Helo_l_WaypointInterpolator'  name='WaypointInterpolator'> 


<fieldValue  name=' wayPoints'  value='6600  600  16800  7592.6  600  16921.4  8585.2  600 

17042.9  9577.8  600  17164.3  10570.4  600  17285.7  11563.0  600  17407.2  12555.6  600  17528.6 

13548.2  600  17650.0  14540.8  600  17771.5  15533.4  600  17892.9  16526.0  600  18014.4  17518.6 
600  18135.8  18511.2  600  18257.2  19503.8  600  18378.7  20496.4  600  18500.1  21489.0  600 
18621.5  22481.6  600  18743.0  23474.2  600  18864.4  24466.8  600  18985.8  25400  600  19100 

24906.2  600  18230.4  24412.4  600  17360.9  23918.5  600  16491.3  23424.7  600  15621.8  22930.9 
600  14752.2  22437.1  600  13882.6  21943.2  600  13013.1  21449.4  600  12143.5  20955.6  600 

11273.9  20800  600  11000  20072.7  600  10313.7  19345.4  600  9627.4  18618.1  600  8941.0 
17890.8  600  8254.7  17163.5  600  7568.4  16436.2  600  6882.1  15708.9  600  6195.7  14981.6  600 

5509.4  14254.3  600  4823.1  13700  600  4300  12777.6  600  3913.9  11855.1  600  3527.7  10932.7 
600  3141.6  10010.2  600  2755.4  9087.8  600  2369.3  8165.4  600  1983.2  7242.9  600  1597.0  6320.5 
600  1210.9  5398.0  600  824.8  5100  600  700  5192.8  600  1695.7  5285.5  600  2691.4  5378.3  600 
3687.1  5471.1  600  4682.8  5563.8  600  5678.4  5656.6  600  6674.1  5749.4  600  7669.8  5842.1  600 

8665.5  5934.9  600  9661.2  6027.7  600  10656.9  6120.4  600  11652.6  6213.2  600  12648.3  6306.0 
600  13643.9  6398.7  600  14639.6  6491.5  600  15635.3  6584.3  600  16631.0  6600  600  16800'/> 
<!--  1  knot  =  0.514444444  meters/second  --> 

<fieldValue  name='defaultSpeed'  value='100'/> 
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<fieldValue  name='pitchUpDownForVerticalWayPoints'  value='false '/> 
<fieldValue  name='lineColor'  value='()  0.8  0'/> 

<fieldValue  name='labelColor'  value='0  0.8  0'/> 

<fieldValue  name='labelOffset'  value='0  5  0'/> 

<fieldValue  name='labelFontSize'  value='3'/> 

<fieldValue  name='traceEnabled'  value =' false '/> 

</ProtoInstance> 

<TimeSensor  DEF='Helol_Clock'  loop='trae'/> 

<!--  ====================  Helicopter  2  Block  ====================  --> 

<TransformDEF='Helo-2'  translation='6600  50  16800 '> 

<Transform> 

<ProtoInstance  DEF='HeloInstance2'  name='AHlSuperCobra'> 

<fieldValue  name='helicopterName'  value='Cobra  CAP  2 '/> 
<fieldValue  name='tailBoomColor'> 

<Appearance> 

<MaterialdiffuseColor='0.5  0.5  0.5 '/> 

</Appearance> 

</fieldValue> 

<fieldV alue  name= 'tailRotorDriveShaftColor  '> 

<Appearance> 

<MaterialdiffuseColor='0.5  0.5  0.5 '/> 

</Appearance> 
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</fieldValue> 

<fieldV alue  name= '  horizontalStabilizerColor'> 
<Appearance> 

<MaterialdiffuseColor='0.5  0.5  0.5 '/> 
</Appearance> 

</fieldValue> 

<fieldV alue  name= '  fuselageColor'> 

<Appearance> 

<MaterialdiffuseColor='0.6  0.6  0.6'/> 
</Appearance> 

</fieldValue> 

<fieldValue  name='cockpitColor'> 

<Appearance> 

<MaterialdiffuseColor='0.6  0.6  0.6'/> 
</Appearance> 

</fieldValue> 

<fieldValue  name='cowlingColor'> 

<Appearance> 

<MaterialdiffuseColor='0.5  0.5  0.5 '/> 
</Appearance> 
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</fieldValue> 

<fieldValue  name='inFlight'  value='true'/> 
</ProtoInstance  > 

</Transform> 


</Transform> 

<ProtoInstance  DEF='Helo_2_WaypointInterpolator'  name='WaypointInterpolator'> 


<fieldValue  name= 'wayPoints'  value='6530  11.5  16800  6530  500  16800  6600  500 
16800  7592.6  500  16921.4  8585.2  500  17042.9  9577.8  500  17164.3  10570.4  500  17285.7 
11563.0  500  17407.2  12555.6  500  17528.6  13548.2  500  17650.0  14540.8  500  17771.5  15533.4 
500  17892.9  16526.0  500  18014.4  17518.6  500  18135.8  18511.2  500  18257.2  19503.8  500 

18378.7  20496.4  500  18500.1  21489.0  500  18621.5  22481.6  500  18743.0  23474.2  500  18864.4 

24466.8  500  18985.8  25400  500  19100  24906.2  500  18230.4  24412.4  500  17360.9  23918.5  500 

16491.3  23424.7  500  15621.8  22930.9  500  14752.2  22437.1  500  13882.6  21943.2  500  13013.1 

21449.4  500  12143.5  20955.6  500  11273.9  20800  500  11000  20072.7  500  10313.7  19345.4  500 

9627.4  18618.1  500  8941.0  17890.8  500  8254.7  17163.5  500  7568.4  16436.2  500  6882.1 

15708.9  500  6195.7  14981.6  500  5509.4  14254.3  500  4823.1  13700  500  4300  12777.6  500 

3913.9  11855.1  500  3527.7  10932.7  500  3141.6  10010.2  500  2755.4  9087.8  500  2369.3  8165.4 
500  1983.2  7242.9  500  1597.0  6320.5  500  1210.9  5398.0  500  824.8  5100  500  700  5192.8  500 
1695.7  5285.5  500  2691.4  5378.3  500  3687.1  5471.1  500  4682.8  5563.8  500  5678.4  5656.6  500 
6674.1  5749.4  500  7669.8  5842.1  500  8665.5  5934.9  500  9661.2  6027.7  500  10656.9  6120.4  500 
11652.6  6213.2  500  12648.3  6306.0  500  13643.9  6398.7  500  14639.6  6491.5  500  15635.3 
6584.3  500  16631.0  6600  500  16800'/> 

<!--  1  knot  =  0.514444444  meters/second  --> 

<fieldValue  name='defaultSpeed'  value='200'/> 

<fieldValue  name='lineColor'  value  ='0.8  0  0'/> 

<fieldValue  name='iabelColor'  value='0.8  0  0'/> 

<fieldValue  name='labelOffset'  value='0  5  0'/> 

<fieldValue  name='iabelFontSize'  value='37> 
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<fieldValue  name='traceEnabled'  value =' false '/> 


</ProtoInstance> 

<TimeSensor  DEF='Helo2_Clock'  loop='true'/> 

<!--  ==============  AAV7PA1  -> 

<TransformDEF='AAV7PAlLocation'  scale='1.25  1.25  1.25' translation='6620 -2  16900'> 

<Inline  url='"<../../AmphibiousVehicles/ AAV/AAV. wrl>" 
'’<http://web.nps.navy.mil/~brutzman/Savage/AmphibiousVehicles/AAV/AAV.wrl>'’ 

"<. ./.  ./AmphibiousVehicles/AAV/AAV.xml> " 

"<http://web.nps.navy.mil/~brutzman/Savage/AmphibiousVehicles/AAV/AAV.xml>"7> 

</Transform> 

<ProtoInstance  DEF='AAV7PAlWaypointInterpolator'  name='WaypointInterpolator'> 

<fieldValue  name='wayPoints'  value='6620  -1  16900  6720  -1  16900  6870  -1  19500 
7400-1  19500  8400-1  16900  6620-1  16900'/> 

<!--  1  knot  =  0.514444444  meters/second  --> 

<fieldValue  name='defaultSpeed'  value='5'/> 

<fieldValue  name='lineColor'  value='0.8  0  0.65'/> 

<fieldValue  name='labelColor'  value='0.8  0  07> 

<fieldValue  name='labelOffset'  value='0  5  0'/> 

<fieldValue  name='labelFontSize'  value='3'/> 

<fieldV alue  name = '  traceEnabled '  value ='  false  '/> 

</ProtoInstance> 

<TimeSensor  DEF='AAV7PA1  Clock'  loop =' true '/> 

</Group> 

<!--  hide  things  here  until  ready  to  bring  them  into  the  active  scene  --> 

<S  witch  whichChoice='0'> 

<!--  Ocean  bathymetry  --> 
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cTransform  rotation='0  1  0  1.5708'  translation^'  1 1 900  0  6000'> 


dnline  ui  l-"'<../../Locations/CampPcndlctonCalifornia/ChartlctTranscribcd.wii>" 
"<http://web.nps.navy.mil/~brutzman/Savage/Locations/CampPendletonCalifornia/ChartletTrans 

cribed.wrl> "  "<../. ■/Locations/CampPendletonCalifomia/ChartletTranscribed.xml> " 
"<http://web.nps.navy.mil/~brutzman/Savage/Locations/CampPendletonCalifomia/ChartletTrans 

cribed.xml>"7> 

</Transform> 

<!--  GeoVmil  versions  will  be  here  someday  --> 

<Group> 


<!--  Southwest  comer  reference  point:  33:12N  117:38W  --> 

<!--  GeoLocation  and  USE  EntireScene  to  follow  --> 

</Group> 

</Switch> 

</Switch> 

<!--  AAAV-1  Waypoint  Routes  --> 

<!--  Helo-1  Waypoint  Routes  --> 

<ROUTE  fromNode='Helol_Clock'  fromField=' is  Active '  toNode='HeloInstancel '  toField='mFlight7> 
<ROUTE  fromNode='Helo_l_WaypointInterpolator'  fromField='totalDuration'  toNode='Helol_Clock' 
toField= 'cycleInterval'/> 

<ROUTE  fromNode='Helol_Clock'  fromField='fraction_changed'  toNode='Helo_l_WaypointInterpolator' 
toField= '  fraction'/> 

<ROUTE  fromNode='Helo_l_WaypointInterpolator'  fromField='positionValue'  toNode= 'Helo-1' 
toField= 'set_translation'/> 

<ROUTE  fromNode='Helo_l_WaypointInterpolator'  fromField='orientationValue'  toNode=' Helo-1' 
toField= 'set_rotation'/> 

<!--  Helo-2  Waypoint  Routes  --> 
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<ROUTE  fromNode='Helo2_Clock'  fromField='isActive '  toNode='HeloInstance2'  toField='inFlight'/> 

<ROUTE  fromNode='FIelo_2_WaypointInterpolator'  fromField='totalDuration'  toNode='Helo2_Clock' 
toField= 'cycleInterval'/> 

<ROUTE  fromNode='Helo2_Clock'  fromField='fraction_changed'  toNode='Helo_2_WaypointInterpolator' 
toField= '  fraction'  /> 

<ROUTE  fromNode='Helo_2_WaypointInterpolator'  fromField='positionValue '  toNode='Helo-2' 
toField= 'set_translation'/> 

<ROUTE  fromNode='FIelo_2_WaypointInterpolator'  fromField='orientationValue'  toNode='FIelo-2' 
toField= 'set_rotation'/> 

<!--  AAV2  -> 

<ROUTE  fromNode='AAAVl_Clock'  fromField='fraction_changed'  toNode='AAV-2PATH'  toField='set_fraction'/> 
<!--  AAV7PA1  Waypoint  Routes  --> 

<ROUTE  fromNode='AAV7PAlWaypointInterpolator'  fromField='totalDuration'  toNode='AAV7PAlClock' 
toField= 'cyclelnterval7> 

<ROUTE  fromNode='AAV7PAl Clock'  firomField='fraction_changed'  toNode='AAV7PAlWaypointInterpolator' 
toField= '  fraction'  /> 

<ROUTE  fromNode='AAV7PAlWaypointInterpolator'  fromField='positionValue'  toNode='AAV7PAl  Location' 
toField= 'set_translation'/> 

<ROUTE  fromNode='AAV7PAlWaypointInterpolator'  fromField='orientationValue '  toNode='AAV7PAlLocation' 
toField= 'set_rotation'/> 

</Scene> 

</X3D> 

<!--  Tag  color  codes:  <NodeName  attribute=' value '/>  --> 
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